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

@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 (правда до конца так и не написано)

Новые блоги и статьи Все статьи Все блоги /
Про "Windows must die!" kumehtar 04.11.2026 Знаете, чет накатило. . . . Когда-то это было почти боевым кличем: мол, нормальный человек сидит на DOS, OS/ 2 или Linux, а вот это вот - Must Die. А теперь человек произносит «мастдай» с усмешкой - и. . .	Красочные поля с номером страницы svg+background-image russiannick 04.11.2026 Красочные поля с номером страницы не менее важны чем в эпоху бумажных книг. Посему спешу представить почтеннейшей публике этот важный инструмент который эти поля и формирует. В процессе разработки. . .	Вступаем в новую фазу генерации favicons, векторную. russiannick 02.11.2026 Теперь нет нужды скрывать что используется простой svg. Исходный код изображения помещаем в поле и жмем кнопку. Исходник преобразуется в вид корректный для помещения в favicon или в url(). Нажатие. . .	Генератор паролей (вариант №4) Maks 01.11.2026 После публикации 3-го варианта генератора паролей, разослал его своим коллегам (с целью оценки), в итоге были получены следующие рекомендации: 1. Вернуть возможность использования знаков \| 1 l I;. . .
Генератор паролей (вариант №3) Maks 30.10.2026 Финальная версия генератора паролей 1С. Доработка решения в этот раз коснулась только визуальной части, а именно, добавлен реквизит ДопПараметры (тип Булево), который скрывает/ отображает реквизиты:. . .	Магическое мышление и магия, современная наука не отличима от магии (говорит ИИ Джемени) zorxor 30.10.2026 Джемени, расскажи, пожалуйста, что такое магическое мышление, что такое магия, почему современная наука чем-то напоминает магию? Фраза «Любая достаточно развитая технология неотличима от магии». . .	За какое время ИИ может подобрать пароль по хешу (рассказывает Джемени ИИ) zorxor 30.10.2026 Расскажи, Джемени, если известен хэш МД5, например, за сколько ИИ сможет подобрать соответствующий пароль? Искусственный интеллект (ИИ) может подобрать простой или средний по сложности пароль по. . .	Кто убил Suno? Почему наше солнышко погасло? (диалог с ИИ Джемени) zorxor 30.10.2026 Как убивали Suno. Хронология. «Убийство» музыкальной нейросети Suno — это затяжной процесс, в котором технологический хайп стартапа разбился о жесткую реальность судебных исков от гигантов. . .

@taras atavin 4226 / 1799 / 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 / 1799 / 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