Здравствуйте, Marty, Вы писали:
A>>i не будет существовать после цикла. A>>Ну и как-то все привыкли. И даже я.
M>Это мелочь. Это было очень давно, когда совокупная кодовая база была не сравнима с текущей
Почему-то тебя это не волнует, когда новый кумпилятор ложит в корку программу, которая нормально работала до этого.
Здравствуйте, Marty, Вы писали:
A>>Для этого нужно ввести в стандарт всего одно ключевое слово neconst, и один флаг кумпилятора — как интерпретировать ситуацию, когда не задан ни тот ни другой модификатор. Я бы справился с этой задачей за один рабочий день.
M>И никто им не будет пользоваться, потому что старую кодовую базу никуда не деть, и любой твой новый код всё равно должен сопрягаться со старой кодовой базой
Ну вот я тебе и говорю, как можно было бы сделать мягкий переход не убив старые исходники.
Мне кажется, что со мной разговаривают два разных Marty.
Один говорит, что я должен залезть в стороннюю библиотеку и исправить там все варнинги,
а другой говорит, что не нужно вносить вполне разумное изменение в синтаксис, потому что исходники трогать нельзя.
Здравствуйте, alpha21264, Вы писали:
S>>Таких как я очень и очень много, судя по количеству const-ов в нормальных кодовых базах и количеству рекомендаций применять const by default от лучших собаководов. Так что нас рать.
A><тролль-мода> A>Интеллектуальное большинство. A></тролль-мода>
Ну так-то да, ссылки на авторитеты не хорошо использовать в качестве доказательтсв в спорах. В то же время, нельзя игнорировать то, что вещи, о которых мы говорим, уже на протяжении многих лет являются стандартами по всему миру во многих коллективах разработчиков С++, если не во всех. Для того, чтобы это переломить, нужно предложить что-то по истине революционное. На голых "я не привык", "я не понимаю" вряд ли это сдвинешь.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Стопудово свернет. Точно так же, как сгенерирует одинаковый код для ++i и i++. Но это вовсе не означает, что нет проблемы. Ты текст по ссылке-то открой.
Открыл. Я не понял, что ты хотел этой ссылкой сказать.
Насчёт преждевременной пессимизации. Я не стал бы писать так (хотя и видел продуктовый код, где именно такое и написано):
for (i = 0; i < strlen(s); i ++) {
. . . .
}
Но уж по мелочи подстраивать код под удобство компилятора, ну его.
Спасибо C++-у, компиляторы стали очень умные. С мелочами сами разберутся.
Здравствуйте, Pzz, Вы писали:
Pzz>Открыл. Я не понял, что ты хотел этой ссылкой сказать.
Смысл прост: не стоить без необходимости усложнять код. А использование указателей на функции в надежде на последующую оптимизацию — это неоправданное усложнение, ИМХО. Зачем усложнять работу компилятору и заставлять его оптимизировать то, чего вообще могло бы не быть при прочих равных условиях?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, 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 не писал, могу только предполагать).
Здравствуйте, rg45, Вы писали:
Pzz>>Открыл. Я не понял, что ты хотел этой ссылкой сказать.
R>Смысл прост: не стоить без необходимости усложнять код. А использование указателей на функции в надежде на последующую оптимизацию — это неоправданное усложнение, ИМХО. Зачем усложнять работу компилятору и заставлять его оптимизировать то, чего вообще могло бы не быть при прочих равных условиях?
Насчёт неусложнения кода без необходимости я полностью согласен. Более того, в некритических по скорости местах (а это — процентов 80 любого проекта) я вполне сознательно могу выбрать сделать проще, а не быстрее. Нет никакой разницы, сколько времени читается конфигурационный файл, одну миллисекунду или две, и если можно написать проще, пусть хоть 5 миллисекунд читается.
Но в данном случае, я считаю, усложнение есть, но не от использования указателей, а от использования нестандартной конструкции, которую, как выясняется, далеко не всякий программист прочтёт, даже и сеньёр-помидор.
Вообще, я считаю, вершина мастерства — выражать сложные вещи таким языком, который без труда поймет даже джун.
Здравствуйте, alpha21264, Вы писали:
M>>Это мелочь. Это было очень давно, когда совокупная кодовая база была не сравнима с текущей
A>Почему-то тебя это не волнует, когда новый кумпилятор ложит в корку программу, которая нормально работала до этого.
Если программа нарушает спецификацию языка, имеет полное право класть. Иначе компиляторы станет невозможно разрабатывать.
В данном случае, программа была синтаксически верна, но семантически — UB.
И я сначала было подумал, вот какой вредный компилятор, понимает, что программа — UB, но вредничает и вместо того, чтобы выругаться, бомбу подкладывает. А потом сообразил, он просто на всех выходах из этой функции без явного return-а подкладывает UB2, без какого-либо анализа, может функция выйти через эту дверь или нет.
Здравствуйте, Pzz, Вы писали:
Pzz>Если у программы сработал assert, значит, у неё с головой уже не всё в порядке. Какой смысл продолжать агонию? Всё равно уже непонятно, куда её дальше занесёт.
Pzz>Критический сервис — ну, на случай его падения должен быть план Б. В диапазоне от "перезапустить" и до "перейти на другой компьютер". На то он и критический, чтобы его падение тоже было штатной ситуацией, из которой предусмотрен выход. В конце концов, он может просто от аппаратной ошибки сломаться, или от сети отвалиться из-за плохого контакта в сетевом разъеме.
Всё так, и пререзапускается у нас автоматом. Но была ситуация — при вычитке, разборе, и дальнейшей обработке сообщения из кафки срабатывал неверный ассёрт, ну так вот вышло, моя лажа. И программа падала, не закоммитив это сообщение. А потом поднималась — и вычитывала его опять...
План Б, конечно, был: выгребли руками это сообщение из очереди. Но пока упало, пока осознали, пока до нас (девов) добрались — время. А у нас private LTE core, пока сервис лежит, абоненты не могут звонить и IoT устройства слать ничего не могут. Клиент нервничал, в результате нервничал я, а я этого не люблю, и ещё больше не любит руководство (справедливо).
Pzz>Мне показывали пальцем на хидер от вендового SDK, там был #ifdef DEBUG ... #endif прямо посреди enum-а. А enum был такой, с автоматически назначаемыми значениями. Т.е., значения этого enum-а были разные для отладочной и релизной сборки. Pzz>Ну его нафиг, еще и такие ошибки мне искать.
Ну неприятно, да... интересно было бы на это глянуть. Но риск такого у меня минимален, т.к. собираю монолит без so, а профит от debug-диагностики реален.
Pzz>Кстати, степень въедливости статического анализа что в gcc, что в clang-е зависят от оптимизации. С выключенной оптимизацией он не делает каких-то видов анализа кода, которые ему и для предупреждений нужны, а не только для кодогенерации.
Не, ну перед коммитом один хрен собирать релиз, да и CI не пропустит билд с предупреждениями. Так что максимум — ну позже починю, чем если бы изначально с релизом работал.
Pzz>ASAN я как-то не осилил. Больно многого они хотят. Например, пересборки библиотек, от которых зависит программа, с ASAN-ом. Это ж полсистемы надо пересобрать да еще как-то бесконфликтно разложить. Нафиг такой инструментарий.
Такого требования, чтобы библиотеки пересобирать, нет. Могут быть сложности, если память выделяетя в библиотеке, а освобождается в прикладном коде, но это само по себе нездорово. У меня библиотеки собираются без ASAN, продукт с ним, и никаких спецэффектов не наблюдал.
Pzz>У меня эти времянки иногда по ошибке утекают в коммит. Так что я стараюсь даже и во времянке дичи не писать.
Худшее — CI обругает ворнингами и билд сломается, не страшно. Совсем дичи я же не пишу.
Здравствуйте, serg_joker, Вы писали:
_>Всё так, и пререзапускается у нас автоматом. Но была ситуация — при вычитке, разборе, и дальнейшей обработке сообщения из кафки срабатывал неверный ассёрт, ну так вот вышло, моя лажа. И программа падала, не закоммитив это сообщение. А потом поднималась — и вычитывала его опять...
А если бы там по делу был assert? А программа не падала бы, а продолжала жить инвалидом?
_>План Б, конечно, был: выгребли руками это сообщение из очереди. Но пока упало, пока осознали, пока до нас (девов) добрались — время. А у нас private LTE core, пока сервис лежит, абоненты не могут звонить и IoT устройства слать ничего не могут. Клиент нервничал, в результате нервничал я, а я этого не люблю, и ещё больше не любит руководство (справедливо).
Похоже, в плане Б не хватает действия на случай, если программа падает без какого-либо прогресса.
Возможно, правильным действием было бы хранить предыдущую версию и автоматически на неё откатываться, если с новой после обновления всё плохо. Ну и там, письма электрические писать во все стороны, чтобы шуму поднять
Pzz>>ASAN я как-то не осилил. Больно многого они хотят. Например, пересборки библиотек, от которых зависит программа, с ASAN-ом. Это ж полсистемы надо пересобрать да еще как-то бесконфликтно разложить. Нафиг такой инструментарий. _>Такого требования, чтобы библиотеки пересобирать, нет. Могут быть сложности, если память выделяетя в библиотеке, а освобождается в прикладном коде, но это само по себе нездорово. У меня библиотеки собираются без ASAN, продукт с ним, и никаких спецэффектов не наблюдал.
А мне питонщики сказали, что есть. Кто из вас неправ?
M>>Это мелочь. Это было очень давно, когда совокупная кодовая база была не сравнима с текущей
A>Почему-то тебя это не волнует, когда новый кумпилятор ложит в корку программу, которая нормально работала до этого.
Видишь ли, это у тебя она случайно работала. А у сотен других их программа работала, но малозаметно подгаживала
Здравствуйте, alpha21264, Вы писали:
M>>И никто им не будет пользоваться, потому что старую кодовую базу никуда не деть, и любой твой новый код всё равно должен сопрягаться со старой кодовой базой
A>Ну вот я тебе и говорю, как можно было бы сделать мягкий переход не убив старые исходники.
Распиши поподробнее, какие шаги ты видишь при этом переходе, а то ничего не понятно
A>Мне кажется, что со мной разговаривают два разных Marty. A>Один говорит, что я должен залезть в стороннюю библиотеку и исправить там все варнинги,
Нет конечно. Сторонние библиотеки собираются просто с отключением варнингов. Жаль что ты не читаешь или не понимаешь, что тебе пишут
A>а другой говорит, что не нужно вносить вполне разумное изменение в синтаксис, потому что исходники трогать нельзя.
Изменение конечно разумное, но никто им пользоваться не будет
Здравствуйте, alpha21264, Вы писали:
A>Почему-то тебя это не волнует, когда новый кумпилятор ложит в корку программу, которая нормально работала до этого.
В твоем случае "нормальная" работа программы была всего лишь частным случаем проявления неопределённого поведения. Но суть неопределённого поведения в том-то и состоит, что ни на какое определённое поведение ты рассчитывать не можешь. Вчера она работала так, а сегодня по-другому. UB — оно в Африке UB.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Pzz, Вы писали:
Pzz>Мне показывали пальцем на хидер от вендового SDK, там был #ifdef DEBUG ... #endif прямо посреди enum-а. А enum был такой, с автоматически назначаемыми значениями. Т.е., значения этого enum-а были разные для отладочной и релизной сборки.
Прям enum? И прям посередине? И автоматический? Можно мне тоже его показать?
Здравствуйте, Marty, Вы писали:
Pzz>>Мне показывали пальцем на хидер от вендового SDK, там был #ifdef DEBUG ... #endif прямо посреди enum-а. А enum был такой, с автоматически назначаемыми значениями. Т.е., значения этого enum-а были разные для отладочной и релизной сборки.
M>Прям enum? И прям посередине? И автоматический? Можно мне тоже его показать?
Сложно. Много лет прошло. Я уже не помню, где это искать.
Так это наверное у них просто всё говнецом ровным слоем обмазано
А так — код который собран с санитайзером — будет проверяться, прочий — нет. Как уже сказали, выделение памяти и освобождение, также думаю и прочие парные действия нужно делать в одном модуле
Здравствуйте, Marty, Вы писали:
Pzz>>А мне питонщики сказали, что есть. Кто из вас неправ?
Pzz>>https://github.com/python/cpython/issues/135774
M>Так это наверное у них просто всё говнецом ровным слоем обмазано
Вообще, я думаю, что питонщики врут. Забыли чего-то проинициализировать, и теперь им лень копать.
Мне тоже лень. Но общий подход радует. И не надо забывать, что Питон может оказаться как раз тем языком, на котором написан скрипт, принимающий запросы из дикого интернета. И при этом этот скрипт будет исполняться с достаточными привелегиями, чтобы набедокурить.
M>А так — код который собран с санитайзером — будет проверяться, прочий — нет. Как уже сказали, выделение памяти и освобождение, также думаю и прочие парные действия нужно делать в одном модуле
Мой пример не выделяет память и не освобождает, а просто зовёт стандартную функцию из стандартной библиотеки питоньего интерпретатора.
Здравствуйте, Pzz, Вы писали:
_>>Всё так, и пререзапускается у нас автоматом. Но была ситуация — при вычитке, разборе, и дальнейшей обработке сообщения из кафки срабатывал неверный ассёрт, ну так вот вышло, моя лажа. И программа падала, не закоммитив это сообщение. А потом поднималась — и вычитывала его опять...
Pzz>А если бы там по делу был assert? А программа не падала бы, а продолжала жить инвалидом?
Выбор сложный, мы решили вот так, урон меньше. Хотя мне тоже нравится, когда падает с корой.
Pzz>Похоже, в плане Б не хватает действия на случай, если программа падает без какого-либо прогресса.
Да, и что? Как после смерти программы чем-то внешним понять почему в общем случае она вперёд не двигается?
Pzz>Возможно, правильным действием было бы хранить предыдущую версию и автоматически на неё откатываться, если с новой после обновления всё плохо. Ну и там, письма электрические писать во все стороны, чтобы шуму поднять
Письма шлются, лаг всё равно есть.
Автоматический откат не всегда поможет, т.к. это же комбинация версии и входных данных. Вохможно, этот ассёрт был воткнут 10 версий назад, просто в эту ветку не заходило.
_>>Такого требования, чтобы библиотеки пересобирать, нет. Могут быть сложности, если память выделяетя в библиотеке, а освобождается в прикладном коде, но это само по себе нездорово. У меня библиотеки собираются без ASAN, продукт с ним, и никаких спецэффектов не наблюдал. Pzz>А мне питонщики сказали, что есть. Кто из вас неправ?
Это memsan всё-таки, а не asan, там таки есть требование пересобирать всё.
Для ASAN тоже желательно пересобирать всё, но требования такого нет, насколько я в курсе, и я на протяжении многих лет на текущем проекте ни разу не столкнулся с проблемами, связанные с тем, что внешние зависимости собираются без ASAN (и вообще релиз), libxml2 и openssl вообще из системных пакетов берутся, а мой код — с asan и debug. Библиотек немного, до 10-ти. Часть C, часть C++. Header-only я не считаю, конечно.
Могу предположить, что в MSVC будет всё хуже, там debug/release CRT плохо уживается и без ASAN.
