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

A>Возвращаемое значение просто не использовалось и программа работала.

Как сама функция возвращала управление, если там нет return? Компилятор раньше вставлял RET, а теперь решил не делать это?

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

A>>Возвращаемое значение просто не использовалось и программа работала.

F>Как сама функция возвращала управление, если там нет return? Компилятор раньше вставлял RET, а теперь решил не делать это?

Как возвращает управление вот такая функция?

void my_func(){ printf("hello world!"); }

F>Дык сборка должна быть warning free (-Werror, /WX) — как раз чтобы не терять важное среди "трёх экранов бессмысленной выдачи".

И всякие относительно безобидные warnings (типа unused variable) будут ошибкой. Это неудобно.
Я вот тоже не понимаю, почему пропущенный return не считается ошибкой компиляции.
Валидных сценариев, либо требований обратной совместимости в этом топике вроде не упоминали.
Всякие там выходы из фунцкии по std::abort или throw не препятствие к тому, чтобы требовать обязательный return в коде.

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

F>>Дык сборка должна быть warning free (-Werror, /WX) — как раз чтобы не терять важное среди "трёх экранов бессмысленной выдачи".

M>И всякие относительно безобидные warnings (типа unused variable) будут ошибкой. Это неудобно.

А зачем писать код, в котором unused variable? Поднимайте культуру разработки.

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

F>>Дык сборка должна быть warning free (-Werror, /WX) — как раз чтобы не терять важное среди "трёх экранов бессмысленной выдачи".

M>И всякие относительно безобидные warnings (типа unused variable) будут ошибкой.

И это хорошо. Прямое указание на что-то лишнее в коде.

M>Это неудобно.

Или отсутствие хороших привычек.

M>Я вот тоже не понимаю, почему пропущенный return не считается ошибкой компиляции.

Полагаю, компилятор просто далеко не всегда может оценить, есть ли return вообще в каждой из потенциальных веток исполнения.
А в простых случаях компиляторы вполне себе диагностируют отсутствие return-а.

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

F>Дык сборка должна быть warning free (-Werror, /WX) — как раз чтобы не терять важное среди "трёх экранов бессмысленной выдачи".

Это более-менее возможно до тех пор, пока в проект не заедет 100500 внешних зависимостей, часть из которых обязательно будет плеваться предупреждениями

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

M>>И всякие относительно безобидные warnings (типа unused variable) будут ошибкой. Это неудобно.

F>А зачем писать код, в котором unused variable? Поднимайте культуру разработки.

А если 90% программы не моя?

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

A>>>А раньше было неопределённое поведение.

_>>Здорово. Правда?

A>Не знаю, мне не понравилось.
A>Программа прекрасно работала несколько лет и при переходе на новый кумпилятор стала падать.

Ты так пишешь как будто неопределенное поведение это нормально.

Я очень давно не программировал и мне тоже непонятно почему тут нет ошибки компиляции. Но именно такое и называлось undefined behavior. Ты можешь считать что прекрасно работает но этот текст некорректный и с другим компилятором все может оказаться не так прекрасно.

-

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

M>Я вот тоже не понимаю, почему пропущенный return не считается ошибкой компиляции.

У нас вот везде установлено

-Werror=return-type

и всё считается.

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Я очень давно не программировал и мне тоже непонятно почему тут нет ошибки компиляции. Но именно такое и называлось undefined behavior. Ты можешь считать что прекрасно работает но этот текст некорректный и с другим компилятором все может оказаться не так прекрасно.

В новых С++ любят делать пакости сюрпризы, и нарушать принцип наименьшего удивления как можно чаще.

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

S>Это более-менее возможно до тех пор, пока в проект не заедет 100500 внешних зависимостей, часть из которых обязательно будет плеваться предупреждениями

у меня внешние зависимости оборачиваются так:

#include "util/warnings/DisableForExternal.h"

#include <optional>
#include <string>
#include <vector>

#include <boost/property_tree/ptree_fwd.hpp>

...

#include "util/warnings/RestoreAfterExternal.h"

<внутрипроектные инклуды>

ну и там в DisableForExternal делается

#    pragma GCC diagnostic push

#    pragma GCC diagnostic ignored "-Wunused-function"
#    pragma GCC diagnostic ignored "-Wunused-variable"
#    pragma GCC diagnostic ignored "-Wunused-parameter"
#    pragma GCC diagnostic ignored "-Wunused-value"
...

В EnableXXX:

#pragma GCC diagnostic pop

Понятно, что там оно для разных компиляторов чуть по-разному, но суть понятна.

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

ЛБ>>Я очень давно не программировал и мне тоже непонятно почему тут нет ошибки компиляции. Но именно такое и называлось undefined behavior. Ты можешь считать что прекрасно работает но этот текст некорректный и с другим компилятором все может оказаться не так прекрасно.

_>В новых С++ любят делать пакости сюрпризы, и нарушать принцип наименьшего удивления как можно чаще.

Моя история на текущем проекте:

Когда я пришёл, то при компиляции вылазила куча предупреждений на стандартном уровне предупреждений.
Одно из того, что я сделал первым — это выставил для всего проекта (-Wall -Werror)
Получил в итоге ~1500 предупреждений, может и больше, не уверен.

Зачистил все, много времени потратил. Где-то пришлось вставить

[[maybe_unused]]

, где-то PROJ_UNUSED(var), где-то ещё чего покрутить.
Уже на этом этапе вычистил какое-то количество багов древних.

Для новых подпроектов дополнительно к

-Wall -Werror

я ставлю

-Wextra -pedantic

И все bool-фции, возвращающие статус (но не только они), помечены

[[nodiscard]]

.

И это не раз ловило баги во вновь написанном коде, ещё до первого запуска.
И было такое, что переход на новый компилятор (я проапдейтил компилятор 4.8.5->8->9->...->14) выдавал новое предупреждение, и оно указывало на ошибку в коде. И одной из них была именно эта, отсутствие return в конце ф-ции.

Так что я лично разработчикам компиляторов благодарен, а "наибольшее удивление" у меня вызывает нежелание пользоваться помощью компилятора и заявления типа "наш код — говно, но оно раньше не падало, а новый С++ компилятор всё сломал. Какие они (С++ компиляторщики) мудаки".

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

N>>А компилятор наверняка тебя предупредил!

A>Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел.
Ой, а какие нонче машины занудные стали — кругом лампочки и пищалки. Ранше, было, садишься — и едешь, а сейчас, понимаешь, пока ремень безопасности не пристегнёшь — пищит. Хорошо хоть заглушки продаются!

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

_>Так что я лично разработчикам компиляторов благодарен, а "наибольшее удивление" у меня вызывает нежелание пользоваться помощью компилятора и заявления типа "наш код — говно, но оно раньше не падало, а новый С++ компилятор всё сломал. Какие они (С++ компиляторщики) мудаки".

Дело же не в этом. А в том что когда компилятор использует UB для явной фигни, могбы по умолчанию предупреждать.

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

F>>А зачем писать код, в котором unused variable? Поднимайте культуру разработки.

A>А если 90% программы не моя?

Так именно и происходить собрал с новыви зависимосяти новым компилятором и всё падает очень удобно.

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

·>Если не влияет, откуда тогда сабж? Как компилятор умудрился сгенерить illegal instruction и зачем?
·>Могу предоложить лишь ситуацию, когда код unreachable:
·>

·>bool f() {
·>  if(inFactAlwaysTrue()) {
·>    return true;
·>  }
·>//never getting here, never crashing
·>}
·>

·>вот наверное тут будет не очень хорошо с т.з. совместимости кидать ошибку компиляции.


Если компилятор видит определение функции inFactAlwaysTrue(), то никакого предупреждения или ошибки не будет. Если же определение функции inFactAlwaysTrue() недоступно, а есть только прототип, то предупреждение или ошибка абсолютно обоснованы

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

S>Здравствуйте, flаt, Вы писали:

F>>Дык сборка должна быть warning free (-Werror, /WX) — как раз чтобы не терять важное среди "трёх экранов бессмысленной выдачи".

S>Это более-менее возможно до тех пор, пока в проект не заедет 100500 внешних зависимостей, часть из которых обязательно будет плеваться предупреждениями

Тоже сталкивался с таким неудобством одно время, чуть ковырял интернеты на этот предмет и обнаружил такой подход как "системные инклюды". Его суть в том, что часть инклюд-путей, настраиваемых проектом для сборочного инструментария, помечаются неким признаком "системный", и на этом основании для тех заголовков, которые размещенны по таким путям, делается чуть-специальная трактовка (они считаются как бы "чужими"), в частности, отключены многие ворнинги. Нкоторые ключевые слова чтобы погуглить: gcc isystem, cmake include_directories SYSTEM

И вот, в своем проекте, при использовании какого ни будь не вполне блестящего 3rdparty, его include-пути проводишь сквозь такой вот system а не просто как для своих, тогда на его заголовки тулчейн не будет сыпать ворнинги как для своего кода.

Здравствуйте, Лазар Бешкенадзе, Вы писали:

ЛБ>Ты так пишешь как будто неопределенное поведение это нормально.

кстати, это действительно нормально. Предложите другие альтернативы. Java? Так она из-за устранения UB поплатилась скоростью. Rust? Адекватный человек его не осилит. С++ — это вполне нормальный компромис.

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

ЛБ>>Ты так пишешь как будто неопределенное поведение это нормально.

SP>кстати, это действительно нормально. Предложите другие альтернативы.

Ты чего-то недопонял. Undefined behavior это про поведение программы а не компилятора. Альтернатива — исправить программу чтобы поведение стало defined.

А писатели компилятора судя по всему просто пошутили. От того что они туда вставили левую инструкцию поведение не стало определенным. Оно как было undefined так и осталось. Видимо ребята считают что они альфе помогли. Если по стандарту это UB то их компилятор standard compliant.

-

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

SP>кстати, это действительно нормально. Предложите другие альтернативы. Java? Так она из-за устранения UB поплатилась скоростью. Rust? Адекватный человек его не осилит. С++ — это вполне нормальный компромис.
Я могу понять, например, обращение к неинициализированным данным... но в данном случае — отсутствие return — неясно что тут такого требующего платить скоростью или усилиями?