@kravam

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

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

0

@taras atavin

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

0

Jupiter

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

0

@kravam

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

0

@OhMyGodSoLong

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

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

0

@taras atavin

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

0

@OhMyGodSoLong

Да они тоже не особо альтернатива. Но они могут обломать компиляцию, если значение не подходит. Просто для 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

Evg

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

0