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

EP>>>Есть третий вариант: во время разработки и тестирования включаются asserts, checked iterators и прочий defensive programming,
EP>·>А во время эксплуатации что делать? Молитву о здравии заказывать?
EP>Тестировать код — это нужно в любом случае. Все эти defensive примочки от багов не исцеляют, а лишь смягчают последствия фейла.
Они фейл делают фейлом, а не UB.

EP>·>Довольно рисково иметь разный код в дебаге и релизе.
EP>Тестируй и debug и release если есть какие-то сомнения в отсутсвии side-effect'ов у assert'ов.
Тут не в сомнениях дело. А сам факт того, что если условие ассерта не сработает в релизе — то угадать что будет — невозможно.

EP>·>assert вот как-то не прижился в managed языках...
EP>ЕМНИП Sinix рассказывал что использует их во всю как раз в managed языке.
Можно, конечно. Но непонятно зачем. А где он об этом писал?

EP>·>Мало они помогают. Переносят проблемы с плеч компилятора на плечи программиста. Угадай — кто чаще ошибается?
EP>Задача писать корректный код лежит на плечах программиста, и никакие defensive штуки не превратят некорректный код в корректный. Максимум в чём они помогают — это раннее определение уже свершившегося бага, да и то в рантайме
Они позволяют избежать UB. Грубо говоря некий такой wysiwyg — как код написан, так он и исполняется. А не так, что вышли за границы массива или обратились к неинициализированной памяти — и последствия совершенно непредсказуемы.
Даже вон JMM придумали, чтобы для многопоточного кода всё было предсказуемо.