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

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

EP>более того — для формально верифицированного кода они не нужны.
Для формально верифицированного их разве кто-то пишет?

EP>·>Если медленно — это уже проблема алгоритма.
EP>Это ещё почему?
Точнее не так. Если медленно, то можно перенести ассерт в юнит-тест.

Добавление ассертов можно оправдать на большой старой кодобазе без единого ЮТ. Ассерт добавить обычно на порядки проще чем ЮТ. Ручные тестеры будут тестить дебаждую сборку. Или давать клиенту и попросить зарепродюсить прод-баг.

EP>·>При хорошем покрытии тестами ценность ассертов падает до нуля.
EP>Точно также как и ценность других defensive примочек, а-ля bounds checking
Не точно также же. В проде bounds checking валит исключения, а ассерты — ничего не делают.

EP>>>С другой стороны, выключение части из проверок в runtime'е, ровно как и отсутствии часть проверок вообще — не делает программу некорректной.
EP>·>Но только если ассерты расставлены корректно.
EP>Что ты имеешь в виду? То что проверка внутри assert'а может иметь side-effect?
Да, и такое бывает, к сожалению.

EP>·>Я что-то не понял что это. Судя по if (!condition)throw это не ассерты в понимании С++.
EP>Там некоторые из них опциональные, и не попадают в Release.
Ух ты. Это как устроено? Что-то не могу разобраться...

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

EP>·>В unmanaged наоборот: когда может — работает правильно, и всегда быстро.
EP>Не всегда быстро, только когда assert'ы отключены.
При релизном использовании отключены.

EP>·>Есть конечно. Я говорю о корректности самого кода, а не логических ошибок в алгоритме.
EP>В чём ты видишь отличие? Выход за пределы bounds это есть логическая ошибка, которой в корректном коде нет
Эта ошибка явно прописана в спеке языка — результат — ArrayOutOfBoundException. Т.е. работает по спеке, однозначно, а не когда вместо исключения у тебя случится, что 1+2=42.

EP>·>Т.е. в С++ если видишь, что у тебя в коде написано a = b + c то при известных значениях b==1 и c==2 может случиться, что a!=3 т.к. где-то что-то стрельнуло по памяти из другого треда. В managed — a==3 всегда, доказано верификатором.
EP>Не доказано — ибо точно также используется не-managed код, точно также есть компилятор в котором могут быть баги, и даже железо может сбоить
Это понятно. Но для типичного приложения компилятор и железо таки можно считать надёжными. К ним применяют гораздо более серьёзные подходы, типа формальной верификации, да и квалификация инженеров выше как правило.

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

EP>2. На основании того насколько корректен его код (здесь речь идёт про библиотеку и пользовательский код, ассерты внутри библиотеки могут ловить ошибки в пользовательском коде).
Конечно, корректен, я что ламер некорректный код писать? А ты как корректность своего кода оцениваешь?
А вообще для этого сценария придумали логи и кастомизируемые (в т.ч. в рантайм) уровни логгирования. Ассерты тут пихать не надо.