Как заставить компилятор не компилить неправильную программу?

@kravam · Регистрация: 04.06.2008

Студворк — интернет-сервис помощи студентам

Мне не даёт покоя разговор с одним программистом, имевший место быть несколько лет назад. Тот сказал, что он так кодит, что у него неправильный код просто-напросто не компилится, а я не стал уточнять. Многое я бы отдал, чтобы вернуться к тому разговору!

Ясно дело, что даже если это и правда, то правда условная. Компилятор же не знает, что нужно человеку. Тем не мене, может есть какие-то способы ограничить поведение (предотвратить его) программы на стадии компиляции при синтаксически правильном коде? Будем здесь их обсуждать. Начнём с простого.

C++
1
2
3
4
5
6
7
8
9
10
int main () {
 int p;
 
 //есть ли способ сделать так, чтобы 
 //компилятор  ругался на присвоение
 //(ЛЮБЫМ способом) переменной p
 //определённого значения, например, 7?
 returtn 0;
 
}

@taras atavin · 30.12.2012, 15:55

Объясни, как компилятор поймёт, для чего этот конструктор предназначен?

Jupiter · 30.12.2012, 20:06

Сообщение от kravam

1) Смотрим перегруженный оператор = класса T
2) Определяем, что параметром к этому оператору может идти какой-нибудь класс T1
3) Пытаемся перетипизировать (T1)8, а не получается
4) Вот и ошибка компиляции. Как-то так.

что-то не пойму что вас сейчас не устраивает когда все так и есть

@kravam · 30.12.2012, 21:34 **[ТС]**

Сообщение от Jupiter

3) Пытаемся перетипизировать (T1)8, а не получается

эту операцию он пытается сделать для всех чисел как я понимаю. А должно быть, чтобы (T1)8 было некорректным приведением типов, а (T1)4 корректным; тогда значение 4 компилятор пропустит, а значение 8 нет.

@OhMyGodSoLong · 30.12.2012, 22:45

Вот проблема в том, что constexpr говорит компилятору, что "это можно использовать при compile-time-вычислениях", но он позволяет использовать определяемое не только в compile-time. Поэтому static_assert в конструктор или приводилку типов не влепить, если только не задавать значения действительно только в compile-time — шаблонами: писать какой-нибудь T1<8>. Так что в принципе можно изнасиловать синтаксис и сделать compile-time-проверку для инициализации каким-то int_<8> и runtime-проверку на обычные инты. Но толку-то?

И альтернативы этому не появится, пока в каком-нибудь очередном C++17 не будет полноценных макросов.

@taras atavin · 31.12.2012, 09:24

А макросы чем помогут? Ошибку в самом запрете/разрешении значения компилятор проглотит всё равно.

@OhMyGodSoLong · 31.12.2012, 11:20

Да они тоже не особо альтернатива. Но они могут обломать компиляцию, если значение не подходит. Просто для int_<8>-то хватит и примитивного #define I(v) int_<v>(), но не для более сложных объектов, где пригодится гарантированно compile-time constexpr, но не с таким сногсшибательным синтаксисом как у темплейтов. Это даже могут быть не макросы, а именно просто compile-time-only constexpr (кодогенерацию при компиляции мейнстрим чё-то пока не заценил).

Но вопрос "на кой хрен" остаётся в силе. Конечно, можно сделать так, чтобы писать Constrained<int, Or<InRange<2, 42>, Not<Even>, Equals<67, 98>>, но ведь проблему зависимости типов это не решит. Эту хрень можно будет гарантированно скастовать только к инту. Остальные касты будут выполняться вместе с проверками в рантайме, а значит, особо нет толку от написания всех ограничений на шаблонах (которые как бы намекают, что проверки на валидность кастов должны выполняться лишь при компиляции), если всё равно 99% проверок будут выполняться в рантайме.

Evg · 31.12.2012, 11:37

Сообщение от kravam

Мне не даёт покоя разговор с одним программистом, имевший место быть несколько лет назад. Тот сказал, что он так кодит, что у него неправильный код просто-напросто не компилится, а я не стал уточнять. Многое я бы отдал, чтобы вернуться к тому разговору!

Основная масса способов, которая растёт преимущественно из Си++ - это способы испоганить исходник на ровном месте. Не надо гнаться за тем, чтобы идиотскими способами ловить ошибки на этапе компиляции. На этапе компиляции надо ловить то, что ловится просто. А сложные вещи лучше пытаться ловить в рантайме, но максимально близко к точке возникновения ошибки. В очередной раз наблюдаю у тебя повышение уровня осознания, так что можешь попробовать почитать тут: https://www.cyberforum.ru/blogs/18334/blog104.html (правда до конца так и не написано)

Новые блоги и статьи Все статьи Все блоги /
Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .
Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))	Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	30.12.2012, 15:55
	Объясни, как компилятор поймёт, для чего этот конструктор предназначен? 0

@OhMyGodSoLong ~ Эврика! ~ 1258 / 1007 / 74 Регистрация: 24.07.2012 Сообщений: 2,002
	30.12.2012, 22:45
	Вот проблема в том, что constexpr говорит компилятору, что "это можно использовать при compile-time-вычислениях", но он позволяет использовать определяемое не только в compile-time. Поэтому static_assert в конструктор или приводилку типов не влепить, если только не задавать значения действительно только в compile-time — шаблонами: писать какой-нибудь T1<8>. Так что в принципе можно изнасиловать синтаксис и сделать compile-time-проверку для инициализации каким-то int_<8> и runtime-проверку на обычные инты. Но толку-то? И альтернативы этому не появится, пока в каком-нибудь очередном C++17 не будет полноценных макросов. 0

@taras atavin 4226 / 1796 / 211 Регистрация: 24.11.2009 Сообщений: 27,562
	31.12.2012, 09:24
	А макросы чем помогут? Ошибку в самом запрете/разрешении значения компилятор проглотит всё равно. 0

@OhMyGodSoLong ~ Эврика! ~ 1258 / 1007 / 74 Регистрация: 24.07.2012 Сообщений: 2,002
	31.12.2012, 11:20
	Да они тоже не особо альтернатива. Но они могут обломать компиляцию, если значение не подходит. Просто для int_<8>-то хватит и примитивного #define I(v) int_<v>(), но не для более сложных объектов, где пригодится гарантированно compile-time constexpr, но не с таким сногсшибательным синтаксисом как у темплейтов. Это даже могут быть не макросы, а именно просто compile-time-only constexpr (кодогенерацию при компиляции мейнстрим чё-то пока не заценил). Но вопрос "на кой хрен" остаётся в силе. Конечно, можно сделать так, чтобы писать Constrained<int, Or<InRange<2, 42>, Not<Even>, Equals<67, 98>>, но ведь проблему зависимости типов это не решит. Эту хрень можно будет гарантированно скастовать только к инту. Остальные касты будут выполняться вместе с проверками в рантайме, а значит, особо нет толку от написания всех ограничений на шаблонах (которые как бы намекают, что проверки на валидность кастов должны выполняться лишь при компиляции), если всё равно 99% проверок будут выполняться в рантайме. 0