Легальный около Цэ++ шный холивар

Цитата Qraizer @ 13.05.15, 15:24

В любом же другом случае, объясни, плз, чем провинились другие классы и экземпляры?

Им просто не повезло: класс с которым они должны взаимодействовать стал невалидным.

Цитата Qraizer @ 13.05.15, 15:24

А проблема конкретного экземпляра конкретного класса решается куда изящнее ...исключением, которое нигде не перехватывается. Поставил обработчик неперехваченных, получил в нём это особое исключение, вытащил оттуда нужную инфу, молотком привёл экземпляр во вменяемое состояние, заменил на нормальное исключение, бросил, размотал стек и вышел.

Начиная с "молотком привел экземпляр..." пожалуйста поподробнее. Что ты имеешь в виду?

Сообщение отредактировано: applegame - 13.05.15, 17:15

Сделал его инвариантным, чтобы мог нормально деструкнуться.

Добавлено 13.05.15, 17:42
Например, тупо выставить поле m_size в 0 у контейнера.

Цитата Qraizer @ 13.05.15, 15:24

А проблема конкретного экземпляра конкретного класса решается куда изящнее ...исключением, которое нигде не перехватывается. Поставил обработчик неперехваченных, получил в нём это особое исключение, вытащил оттуда нужную инфу, молотком привёл экземпляр во вменяемое состояние, заменил на нормальное исключение, бросил, размотал стек и вышел.

По-моему и у нас с тобой случился разговор из разряда:

- трава же зеленого цвета?!
- нет, пол-восьмого!



Процитированное тобой именно я и утверждал выше. Ловим возможные исключения. Если удается привести процесс выполнения в нужное состояние - приводим в обработчиках исключений. Если не получается -> вывод причины + отмена операции (или вовсе полное завершение программы). А ты мне про какие-то длинные прыжки рассказываешь Ну не вписывается все это в структурное программирование, но удобно и понятно. "Неструктурным черным ящичкам" - жить!

Цитата Qraizer @ 13.05.15, 17:41

Сделал его инвариантным, чтобы мог нормально деструкнуться.

Весьма плохо себе это представляю. Допустим из-за переполнения буфера в сторонней библиотеке, указатель на некий объект стал указывать неизвестно куда. Каким интересно молотком его выравнивать?

Цитата applegame @ 13.05.15, 18:34

Допустим из-за переполнения буфера в сторонней библиотеке, указатель на некий объект стал указывать неизвестно куда. Каким интересно молотком его выравнивать?

Лично я бы в таком случае реализовал выход из программы по assert'у. Чужие либы с багами - это мина на неизвлечении.

Впрочем во многом Qraizer прав. В общем случае ассерты вполне себе годная штука, но реализация их в C++ все же корявая. Я так подумал, на самом деле ассерты в виде полноценных исключений, мне нравятся больше (в D именно такие). Просто нужно нарисовать грамотную иерархию исключений. Например создать некий assert_error, который унаследовать от std::logic_error и в большинстве случаев, вместо ассертов, спокойно кидаться им. Иногда ассерты ловить полезно, у меня есть моменты в проекте (на D), где нарушение инварианта - вполне себе обрабатываемое событие: просто убивается файбер/сопрограмма вместе с UB, которое создалось из-за нарушения контрактов. Само приложение продолжает работать. А возникшее UB обнаружитвается в логах и впоследствии лечится.

Сообщение отредактировано: applegame - 13.05.15, 19:48

Просто assert'ы были сделаны не для C++. И планировалось пользоваться ими только для целей нарушения условий, в основном во время отладки. Поэтому при объявлении NDEBUG ассерты превращаются в простые нолики. Поэтому и работают не так, как следовало бы, чтобы они нормально вписывались в C++.
Для C++ действительно лучше иметь отдельную от C реализацию такой проверки.

Цитата JoeUser @ 13.05.15, 18:22

"Неструктурным черным ящичкам" - жить!

Правильно. Холивар о goto можно закрывать.
amk, тут дело даже не в языке, по-моему. Просто с тех бородатых времён, когда C только появился, сами технологии проектирования ПО изменились. Сейчас даже в C просто прибивать процесс assert()-ом не всегда удачная идея при нынешнем положении дел в индустрии.

Добавлено 13.05.15, 20:25

Цитата applegame @ 13.05.15, 18:34

Допустим из-за переполнения буфера в сторонней библиотеке, указатель на некий объект стал указывать неизвестно куда. Каким интересно молотком его выравнивать?

Та хоть new char. Не всё ли равно? Лишь бы delete в деструкторе ублажить.

Добавлено 13.05.15, 20:30
P.S. Ты, видимо, не знаком с принципами проектирования критически надёжного кода. Ну, это моя вина, я только с таким последние 10 лет только и связан по роду деятельности, поэтому как-то уже не приемлю других критериев просто по привычке. Один из основополагающих факторов – отказ работоспособности одной подсистемы не должен приводить к отказам в других. Так что проблемы конкретного объекта должны оставаться его личными проблемами.

Цитата Qraizer @ 13.05.15, 20:23

P.S. Ты, видимо, не знаком с принципами проектирования критически надёжного кода. Ну, это моя вина, я только с таким последние 10 лет только и связан по роду деятельности, поэтому как-то уже не приемлю других критериев просто по привычке. Один из основополагающих факторов – отказ работоспособности одной подсистемы не должен приводить к отказам в других. Так что проблемы конкретного объекта должны оставаться его личными проблемами.

Не то чтобы совсем не знаком. Но опыта маловато. Фактически только последний проект стараюсь писать с подобным подходом. Так как терять реальные деньги из-за несмертельных ассертов не хочется.

Стоп, а вы про классические assert'ы говорите, которые из #include <assert.h>? Эти вообще нигде и никак не надо использовать. Вместо них нужны свои макросы, которые и дамп для отладчика сделают, и все логи корректно закроют, и всякую другую полезную информацию сохранят (посмертный скриншот например и значения ключевых данных).

Цитата Pacific @ 14.05.15, 07:13

Эти вообще нигде и никак не надо использовать.

Прям вот так вот категорично? А если мне не нужны скриншоты, если логирование не имеет своей собственной буферизации(т.е. достаточно того, что файлы будут закрыты при смерти процесса), если для отладки мне вполне достаточно корки, которую сделал этот самый assert?

Цитата Pacific @ 14.05.15, 07:13

посмертный скриншот например

А также посмертный список паролей, адресной книги и прочей неконфиденциальной информации.

Цитата D_KEY @ 14.05.15, 08:47

Прям вот так вот категорично? А если мне не нужны скриншоты, если логирование не имеет своей собственной буферизации(т.е. достаточно того, что файлы будут закрыты при смерти процесса), если для отладки мне вполне достаточно корки, которую сделал этот самый assert?

А вызов abort откладывает корку? Давно я это говно не вызывал...
В любом случае, отладчики с этим говном дружат плохо, что выявляется при попытке воспроизвести баг. Сишные ассерты должны умереть.

applegame
Я про внутренние билды для тестеров говорю.

Цитата MyNameIsIgor @ 14.05.15, 09:25

Сишные ассерты должны умереть.

Кому должны? Умирает то, что не используют. Они итак еле живы, но иногда их используют, а значит и умирать они не должны.