Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Тут не в сомнениях дело. А сам факт того, что если условие ассерта не сработает в релизе — то угадать что будет — невозможно.
EP>assert'ы применяются намного шире чем простейший bounds checking — для проверки пред/пост-условий, для проверки инвариантов и вариантов циклов, для проверки инвариантов классов и т.п.
А что они дают-то? Почему вместо assert x просто нельзя if(!x) throw Boom()? Если медленно — это уже проблема алгоритма. При хорошем покрытии тестами ценность ассертов падает до нуля.

EP>И да, если твой вариант цикла неверный, а assert'ы либо выключены, либо вообще не написаны, либо бывает что их вообще невозможно выразить в коде — то действительно угадать что будет невозможно, это типичный баг в программе
EP>Вопрос к тебе — когда ты написал последний assert/проверку для варианта цикла? Если ты не пишешь проверку каких-то свойств корректности программы, это не значит что их нет, и да — здесь применим весь твой пессимизм "угадать что будет — невозможно"
Никогда не писал.

EP>С другой стороны, выключение части из проверок в runtime'е, ровно как и отсутствии часть проверок вообще — не делает программу некорректной.
Но только если ассерты расставлены корректно.

EP>>>ЕМНИП Sinix рассказывал что использует их во всю как раз в managed языке.
EP>·>Можно, конечно. Но непонятно зачем. А где он об этом писал?
EP>Много где, можем попробовать его призвать сюда. Например в CodeJam сделали компонент Assertions.
Я что-то не понял что это. Судя по if (!condition)throw это не ассерты в понимании С++.

EP>В целом не пойму почему ты проводишь разделение managed/не managed относительно assert'ов.
Это в ответ на то, что в С++ "включаются asserts, checked iterators и прочий defensive programming". Ассерты тут как частный случай скорее.
Т.е. в managed у тебя всегда работает правильно, а когда может — работает быстро. В unmanaged наоборот: когда может — работает правильно, и всегда быстро.

EP>>>Задача писать корректный код лежит на плечах программиста, и никакие defensive штуки не превратят некорректный код в корректный. Максимум в чём они помогают — это раннее определение уже свершившегося бага, да и то в рантайме
EP>·>Они позволяют избежать UB. Грубо говоря некий такой wysiwyg — как код написан, так он и исполняется. А не так, что вышли за границы массива или обратились к неинициализированной памяти — и последствия совершенно непредсказуемы.
EP>Это лишь только для мизерной части утверждений корректности программы. Если ты не расписал все утверждения корректности, то никакого "WYSIWYG" — очевидно нет
Есть конечно. Я говорю о корректности самого кода, а не логических ошибок в алгоритме. Т.е. в С++ если видишь, что у тебя в коде написано a = b + c то при известных значениях b==1 и c==2 может случиться, что a!=3 т.к. где-то что-то стрельнуло по памяти из другого треда. В managed — a==3 всегда, доказано верификатором.

EP>P.S. Ничто не мешает оставить часть assert'ов включенных в Release. Для этого их обычно разбивают на классы "быстрые", "медленные", "очень медленные" — и уже пользователь библиотеки решает что попадёт в Release.
По-моему излишнее усложнение. Собственно на основании чего пользователь будет принимать решение?