Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>>>Ты так пишешь как будто неопределенное поведение это нормально.
SP>>кстати, это действительно нормально. Предложите другие альтернативы.
ЛБ>Ты чего-то недопонял. Undefined behavior это про поведение программы а не компилятора. Альтернатива — исправить программу чтобы поведение стало defined.
Вот что мешает компилятору в случае отсутствия return вместо падения программы возаращать 0? Ведь в случае неопределённого поведения можно делать что угодно, то почему выбирают наимолее деструктивный вариант?
Где в стандарте написано, в случае разначтений гадить по максимуму.
ЛБ>А писатели компилятора судя по всему просто пошутили.
Что-то с чувством юмора у них так сабе.
Здравствуйте, kov_serg, Вы писали:
_>Вот что мешает компилятору в случае отсутствия return вместо падения программы возаращать 0? Ведь в случае неопределённого поведения можно делать что угодно, то почему выбирают наимолее деструктивный вариант? _>Где в стандарте написано, в случае разначтений гадить по максимуму.
Какой ноль? Если возвращается объект?
Я, кстати, неоднократно откушивал говнеца, когда забывал сделать возврат, и лень было разбираться в простыне варнингов, среди которых были и предупреждения о том, что нет return. А если бы вставлялась такая инструкция, то падало бы сразу и в конкретном месте, ничего бы искать не надо было
Здравствуйте, serg_joker, Вы писали:
A>>Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел. _>Ой, а какие нонче машины занудные стали — кругом лампочки и пищалки. Ранше, было, садишься — и едешь, а сейчас, понимаешь, пока ремень безопасности не пристегнёшь — пищит. Хорошо хоть заглушки продаются!
Аналогия неуместна.
Вот если бы я из-за этих лампочек и пищалок не смог бы спидометр увидеть... то я бы на такой машине просто не поехал бы.
Здравствуйте, Marty, Вы писали:
_>>Вот что мешает компилятору в случае отсутствия return вместо падения программы возаращать 0? Ведь в случае неопределённого поведения можно делать что угодно, то почему выбирают наимолее деструктивный вариант? _>>Где в стандарте написано, в случае разначтений гадить по максимуму.
M>Какой ноль? Если возвращается объект?
M>Какой ноль? Если возвращается объект?
Какая разница, ведь UB да и ABI есть в котором целочисленный результат складывают в аккумулятор. И да если для poison нет значения то его надо ill2 преобразовать. Но это от лени, а не потому что стандарт велит.
Вот что компилятор делает если не хватает ; ?
Что мешает просто останавливать компилякию и сообщать об ошибке?
Здравствуйте, alpha21264, Вы писали:
A>>>А раньше было неопределённое поведение.
N>>А компилятор наверняка тебя предупредил!
A>Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел.
Вообще-то компилятор практически всегда по делу говорит. Надо привыкать к тому, чтобы проект нормально собирался с опциями /Wall /Werror, тогда ничего не пропустишь
Здравствуйте, serg_joker, Вы писали:
_>у меня внешние зависимости оборачиваются так:
ЕМНИП, то сталкивался с ситуациями, когда include из сторонней библиотеки проходит без предупреждений (в том числе из-за вот-таких вот прагм), но потом возникают предупреждения когда в моем коде инстанциируются шаблоны из сторонней библиотеки.
Так что способ и геморройный (когда нужно поддерживать большую тройку компиляторов), и не 100% надежный.
Кроме того, его еще и нужно регулярно подрихтовывать при обновлении зависимостей (новый код ведет к новым предупреждениям) и версий компиляторов.
Но да, если ставить цель получить компиляцию вообще без предупреждений, то либо так, либо как ниже подсказал
Здравствуйте, Marty, Вы писали:
A>>Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел.
M>Вообще-то компилятор практически всегда по делу говорит.
Факты говорят обратное. Сейчас 90% выдачи компилятора — это предупреждения на const, которые вообще никогда не приведут к ошибкам.
Здравствуйте, alpha21264, Вы писали:
A>Сейчас 90% выдачи компилятора — это предупреждения на const, которые вообще никогда не приведут к ошибкам.
А пример такого предупреждения можно? А то как-то субъективный опыт подсказывает, что когда что-то подозрительное происходит вокруг const, то ошибки уже не за горами.
Здравствуйте, ·, Вы писали:
·>Я могу понять, например, обращение к неинициализированным данным... но в данном случае — отсутствие return — неясно что тут такого требующего платить скоростью или усилиями?
да всё тоже самое. Отсутствие return по сути — это обращение к неинициализированной памяти:
int foo() {}
void main() {
foo();
foo();
const auto res = foo(); //UB
}
в данном случае результат вызова foo никак не обрабатывается. Зачем нам тратить такт процессора и записывать принудительно какое-то значение в eax? Вот компилятор и не тратит. Как только попытались получить доступ к памяти, получили UB. Романтика. Это же одна из основных идей языка. Не платить за то, что не используем.
Здравствуйте, sergii.p, Вы писали:
SP>·>Я могу понять, например, обращение к неинициализированным данным... но в данном случае — отсутствие return — неясно что тут такого требующего платить скоростью или усилиями? SP>да всё тоже самое. Отсутствие return по сути — это обращение к неинициализированной памяти:
SP>int foo() {}
SP>void main() {
SP> foo();
Как я понимаю, UB уже тут. В интернете пишут:
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.
SP>в данном случае результат вызова foo никак не обрабатывается.
Как я понимаю, у топикстартера тоже не обрабатывалось и упало.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alpha21264, Вы писали:
M>>Вообще-то компилятор практически всегда по делу говорит.
A>Факты говорят обратное. Сейчас 90% выдачи компилятора — это предупреждения на const, которые вообще никогда не приведут к ошибкам.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, Marty, Вы писали:
A>>>Типа да. Но он сейчас стал таким занудным — на трёх экранах бессмысленной выдачи я это сообщение просмотрел.
M>>Вообще-то компилятор практически всегда по делу говорит.
A>Факты говорят обратное. Сейчас 90% выдачи компилятора — это предупреждения на const, которые вообще никогда не приведут к ошибкам.
как правило
90% компилятора практически в любом проекте
это касты с/в unsigned интегральные типы
Здравствуйте, Marty, Вы писали:
M>>>Вообще-то компилятор практически всегда по делу говорит.
A>>Факты говорят обратное. Сейчас 90% выдачи компилятора — это предупреждения на const, которые вообще никогда не приведут к ошибкам.
M>Какие такие предупреждения о const?
Вот такие:
void my_func( char *Str ) // тут может быть и не char
{
// Совершенно не важно, что здесь, но Str не меняется
}
my_func( "my string" ); // вот тут будет бессмысленный warning
При этом все эти const заметно захламляют код и не несут никакого смысла.
Здравствуйте, alpha21264, Вы писали:
M>>Какие такие предупреждения о const?
A>Вот такие: A>
A>void my_func( char *Str ) // тут может быть и не char
A>{
A> // Совершенно не важно, что здесь, но Str не меняется
A>}
A>my_func( "my string" ); // вот тут будет бессмысленный warning
A>
Ох уж этот мощный запах говнокода!
A>При этом все эти const заметно захламляют код и не несут никакого смысла.
Такое ощущение, что вы продолжаете жить в 1980-х. Уже к середине 1990-х такое стало моветоном.
S>ЕМНИП, то сталкивался с ситуациями, когда include из сторонней библиотеки проходит без предупреждений (в том числе из-за вот-таких вот прагм), но потом возникают предупреждения когда в моем коде инстанциируются шаблоны из сторонней библиотеки.
Да, такое бывало, к сожалению. Правда, если не ошибаюсь, я такое на MSVC наблюдал, а на gcc — нет. По крайней мере, последние пару лет, я не сталкивался с таким (у нас gcc-only сейчас).
S>Так что способ и геморройный (когда нужно поддерживать большую тройку компиляторов), и не 100% надежный. S>Кроме того, его еще и нужно регулярно подрихтовывать при обновлении зависимостей (новый код ведет к новым предупреждениям) и версий компиляторов.
Всё так, геморойно и не 100% надёжно, но в итоге всё равно делать нужно (на мой взгляд), ибо отказываться от диагностики дороже в перспективе.
а тут уже начинается интересный пласт вопросов. Доказать, что функция не на всех возможных путях вернула значение (что как я догадываюсь, теоретически невозможно)
не будем придираться к самой функции. Поколения криворуких программистов могут сделать и не такое. Тут формально return нет и clang честно пишет предупреждение control reaches end of non-void function но в asm генерирует абсолютно корректный код. То есть компилятор признал что код с душком, но полез делать маленькие оптимизации из предположения что это корректная программа и смог дойти до правильного ответа.
А теперь представим, что у нас не такой синтетический пример, а что-то реальное с закрученной логикой листов на 5.
p.s опять же UB тут по ветке по-моему понимают несколько привратно. Дескать если компилятор видит UB, он может делать любую дичь. Но он как раз предполагает, что в программе UB быть не может и делает оптимизации из этого предположения. То есть если в программе на какой-то ветке нет return, да, для компилятора это сигнал что тут UB. Но он сделает предположение, что программа туда просто не дойдёт или в этом случае никто результат проверять не будет. То есть в runtime всё сложится так, что в конечном коде UB исчезнет.
Что произошло у ТС — не понимаю. Возможно, это бунт разработчиков компилятора, их следует признать еретиками и сжечь на костре.
