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

Pzz>Ты не представляешь, сколько раз мне приходилось спорить с коллегами на тему, с какого это такого хрена я оставляю в релизной сборке assert-ы (обычно не либсишные, а самодельные, которые умеют прощальные слова в лог писать, а не куда придётся).
С подходом по ассёртам в целом согласен, за исключением того, что в релизе у меня по умолчанию они не сваливают всё-таки программу, а пишут в журнал условие и стек. Ну и можно через переменную окружения настроить поведение (можно полностью отключить, можно вызывать abort). К сожалению, иногда стреляет и в проде. Хотя всё меньше и меньше, но бывает. Изначально у меня тоже abort звало в проде, но была ситуация, когда ассёрт был ошибочным, и раз упавшая программа уже не поднималась, это вызвало реакцию, которую я больше переживать не хочу

Pzz><...> я не и делаю отдельных отладочных сборок, зачем мне тестировать и отлаживать дебугную сборку, если пользователю я поставляю релизную?
Тут не соглашусь, в дебажной сборке кроме моих ассёртов включаются ещё и внутренние проверки stl/libc всякие там проверки валидности итераторов и прочее. Да и сам я вставляю больше проверок инвариантов, которые в прод. всё-таки слишком дороги с т.з. времени выполнения. Да, отсутствие оптимизаций делает программу другой, но я на практике не сталкивался с тем, чтобы дебаг работал, а релиз — нет именно из-за включившегося оптимизатора, UB с этим связанного и прочего. А вот доп. проверки дебажного варианта stl что-то, было, и ловили.
И дебаг — с ASAN, тоже в релиз не покладёшь.
А, ну и на дебаг у меня нет -Werror, т.к. по месту, бывает, втыкаю мусорный код для отладки, где nodiscard игнорируется или приведение типа не делается явное или знак/беззнак сравнивается или ещё чего подобное, что недопустимо в коммит, но во времянке можно.

Полагаю, что различия в этой части у нас с тобой связаны в различиях между C++ и go инструментариями (на go не писал, могу только предполагать).