Здравствуйте, serg_joker, Вы писали:
Pzz>>Ты не представляешь, сколько раз мне приходилось спорить с коллегами на тему, с какого это такого хрена я оставляю в релизной сборке assert-ы (обычно не либсишные, а самодельные, которые умеют прощальные слова в лог писать, а не куда придётся).
_>С подходом по ассёртам в целом согласен, за исключением того, что в релизе у меня по умолчанию они не сваливают всё-таки программу, а пишут в журнал условие и стек. Ну и можно через переменную окружения настроить поведение (можно полностью отключить, можно вызывать abort). К сожалению, иногда стреляет и в проде. Хотя всё меньше и меньше, но бывает. Изначально у меня тоже abort звало в проде, но была ситуация, когда ассёрт был ошибочным, и раз упавшая программа уже не поднималась, это вызвало реакцию, которую я больше переживать не хочу 
Если у программы сработал assert, значит, у неё с головой уже не всё в порядке. Какой смысл продолжать агонию? Всё равно уже непонятно, куда её дальше занесёт.
Критический сервис — ну, на случай его падения должен быть план Б. В диапазоне от "перезапустить" и до "перейти на другой компьютер". На то он и критический, чтобы его падение тоже было штатной ситуацией, из которой предусмотрен выход. В конце концов, он может просто от аппаратной ошибки сломаться, или от сети отвалиться из-за плохого контакта в сетевом разъеме.
P.S. Я как-то работал в конторе, они там изобрели микросервисы. В том смысле, что их программа состояла из нескольких взаимодействующих процессов. Которые поднимались/запускались в определенной последовательности, и в случае падения перезапускались.
Я, как раз, отвечал за перезапускалку (ну и еще кой за чего, что к делу не относятся).
Так вот, у них там какой-то сервис падал на каждом запросе. Узнали они это, когда решили производительность протестировать. А так, перезапускалка работала штатно, падение и перезапуск сервиса было не заметно.
Pzz>><...> я не и делаю отдельных отладочных сборок, зачем мне тестировать и отлаживать дебугную сборку, если пользователю я поставляю релизную?
_>Тут не соглашусь, в дебажной сборке кроме моих ассёртов включаются ещё и внутренние проверки stl/libc всякие там проверки валидности итераторов и прочее. Да и сам я вставляю больше проверок инвариантов, которые в прод. всё-таки слишком дороги с т.з. времени выполнения. Да, отсутствие оптимизаций делает программу другой, но я на практике не сталкивался с тем, чтобы дебаг работал, а релиз — нет именно из-за включившегося оптимизатора, UB с этим связанного и прочего. А вот доп. проверки дебажного варианта stl что-то, было, и ловили.
Мне показывали пальцем на хидер от вендового SDK, там был #ifdef DEBUG ... #endif прямо посреди enum-а. А enum был такой, с автоматически назначаемыми значениями. Т.е., значения этого enum-а были разные для отладочной и релизной сборки.
Ну его нафиг, еще и такие ошибки мне искать.
Кстати, степень въедливости статического анализа что в gcc, что в clang-е зависят от оптимизации. С выключенной оптимизацией он не делает каких-то видов анализа кода, которые ему и для предупреждений нужны, а не только для кодогенерации.
_>И дебаг — с ASAN, тоже в релиз не покладёшь.
ASAN я как-то не осилил. Больно многого они хотят. Например, пересборки библиотек, от которых зависит программа, с ASAN-ом. Это ж полсистемы надо пересобрать да еще как-то бесконфликтно разложить. Нафиг такой инструментарий.
_>А, ну и на дебаг у меня нет -Werror, т.к. по месту, бывает, втыкаю мусорный код для отладки, где nodiscard игнорируется или приведение типа не делается явное или знак/беззнак сравнивается или ещё чего подобное, что недопустимо в коммит, но во времянке можно.
У меня эти времянки иногда по ошибке утекают в коммит. Так что я стараюсь даже и во времянке дичи не писать.
_>Полагаю, что различия в этой части у нас с тобой связаны в различиях между C++ и go инструментариями (на go не писал, могу только предполагать).
Ну я еще и на Си пишу.
