void my_func( char *Str ) // тут может быть и не char
{
// Совершенно не важно, что здесь, но Str не меняется
}
my_func( "my string" ); // вот тут будет бессмысленный warning
S>Ох уж этот мощный запах говнокода!
Простите, где? Начнём с того, где тут вообще код?
Мне кажется, что ты совершенно неуместно кидаешься эпитетами.
A>>При этом все эти const заметно захламляют код и не несут никакого смысла.
S>Такое ощущение, что вы продолжаете жить в 1980-х. Уже к середине 1990-х такое стало моветоном.
Я знаю. Я действительно не стильно-модно-молодёжный.
Но если начать меряться пиписьками, я думаю, что у меня будет длиннее...
Здравствуйте, alpha21264, Вы писали:
S>>Ох уж этот мощный запах говнокода!
A>Простите, где?
В вашем примере.
A>Начнём с того, где тут вообще код?
Да вот же:
void my_func( char *Str )
my_func( "my string" );
у строкового литерала "my string" тип const char[10], который автоматически безопасно кастится к const char*.
При передаче этого const char* в ваш my_func происходит потеря const на ровном месте. Что есть говнокод.
A>Мне кажется, что ты совершенно неуместно кидаешься эпитетами.
Мне кажется, что я чуть-чуть больше вашего разбираюсь в предмете не смотря на ваши лишние сантиметры.
Может быть потому, что стараюсь узнавать про новое-модное-молодежное с целью понять как это упрощает жизнь и повышает надежность кода.
Например, про разницу между char* и const char* узнал где-то году в 1993-ем или 1994-ом.
Допустим, по каким-то очень важным причинам мы не можем настроить проект так, чтобы он был чист с точки зрения предупреждений компилятора и мы просто увидели, что ф-ция может проваливаться в ветку без return. Хотя это само по себе вызывает у меня вопросы к коду и людям, его поддерживающим.
Но вот дальше, я вот реально не понимаю, вот ТС и люди, солидарные с ним.
Вы действительно хотите, чтобы для такого кода:
bool ShouldBackup(int day) {
if (day % 2)
return false;
// ну забыли `return true`, с кем не бывает
}
void BackupOnEvenDay() {
if (ShouldBackup(dayOfYear())) {
backup();
}
}
, вместо того, чтобы программа упала с криком "чувак, ты налажал!", ф-ция ShouldBackup была просто тождественно равной false?
И потом отлаживаться сильно дальше, не понимая, какого хрена? Ясно, что в таком плоском примере всё очевидно, но обычно же оно сильно не так.
Неужели быстрая смерть, ровно один раз, с крайне простой диагностикой хуже, чем, программа, которая ведёт себя странно?
А если ф-ция возвращает int, на который сильно позже что-то делится? Один хрен будем иметь креш (вы же хотите, чтобы компилятор нолик втулил за вас), только не в том месте, где это элементарно диагностируется и чинится.
Вот если ваша программа открывает файл на чтение-запись там, где необходимо и достаточно только чтение, а потом кто-то починит права на файл и ваша программа свалится, вы тоже будете обвинять того, кто права починил?
Имхо, детерменированно нерабочая программа лучше, чем программа, только похожая на рабочую.
Здравствуйте, serg_joker, Вы писали:
_>Вы действительно хотите, чтобы для такого кода:
тут не вопрос в нашем желании. Большинство более-менее ориентированы на безопасность. Это потому, что у нас ресурсов обычно хоть попой жуй. Но С++ рассчитан больше на людей, которые программируют под чайник или мусорное ведро.
Давайте посмотрим такой код:
enum class Type {
Unknown,
_1,
_2,
_3
};
Type parse(int flag) {
switch (flag & 3){
case 0: return Type::_1;
case 1: return Type::_2;
case 2: return Type::_3;
}
}
здесь по вашей логике надо истошно кричать и материться: забыли default или return. Но с точки зрения программиста, у него не может прийти код 3. Может у него раньше стоит проверка и сразу делается вывод об ошибке. Зачем ему явно обрабатывать невозможный сценарий? Тем более что в результате добавления return мы получим вместо 2-х инструкций 4. А функцию с 4 инструкциями компилятор может уже не захотеть инлайнить, например. А если даже захочет, то это уже рост кода на n*2. Так зёрнышко по зёрнышку и мы не влезем в память нашего чайника.
Причём в С++ давно нашли решение этой дилеммы. Те, кому нужна безопасность, просто обвешиваются санитайзерами и не лезут в дела других. Но конечно человек так не умеет. Ему обязательно надо рассказать остальным почему они мудаки и поступают неправильно
Здравствуйте, sergii.p, Вы писали:
SP> Но С++ рассчитан больше на людей, которые программируют под чайник или мусорное ведро.
Очень спорное утверждение. Я не знаю ни одного С++ программиста, программирующего под чайник или мусорное ведро, а знакомых плюсовиков у меня много. Но даже если бы и да, то это ни на что не влияет, см. ниже. Впрочем, боль людей, пишущих для чайников, я действительно могу не понимать в силу отсутствия такого опыта.
SP>Давайте посмотрим такой код:
<cut>
Давайте.
SP>здесь по вашей логике надо истошно кричать и материться: забыли default или return. Но с точки зрения программиста, у него не может прийти код 3.
Да, нужно истошно кричать и материться. Компилятор не должен думать, что там за логика у программиста. Программист у себя в голове держит мысль "мамой клянусь, не может быть (flag & 3) == 3". А вот если этот флаг прилетит из поломанного пакета или из файла, записанного несовместимой версией, или ещё откуда, или предыдущий парсинг сломан, и в месте, где мы ожидаем флаг, лежит что-то такое, у чего младшие биты 0b11, то окажется, что мамой клялись напрасно.
Более того, если таки провал в ветку без return не случится, то и invalid instruction не будет, т.к. мы до ud2 не дойдём. А если дошли, то программист имел в голове неверные допущения.
Если программист "зуб даёт", то у него в современном компиляторе (а мы ведь на них жалуемся) есть масса способов выразить эту мысль: assert, [assume]], std::unreachable, да хоть abort() позови в ветке default, можно хоть return Type::Unknown, мы же всё равно в эту ветку не попадём, правда?
SP>Может у него раньше стоит проверка и сразу делается вывод об ошибке.
Может. А может, и нет, компилятору об этом откуда знать?
SP> Зачем ему явно обрабатывать невозможный сценарий?
Затем, чтобы показать компилятору, что мы знаем, что делаем. std::unreachable убирает предупреждение и более на генерацию кода не влияет.
SP> Тем более что в результате добавления return мы получим вместо 2-х инструкций 4. А функцию с 4 инструкциями компилятор может уже не захотеть инлайнить, например. А если даже захочет, то это уже рост кода на n*2. Так зёрнышко по зёрнышку и мы не влезем в память нашего чайника.
Нет, не получим.см. здесь, например. Добавление std::unrechable() убирает предупреждение и никаким иным образом на выхлоп не влияет. Ну или приведите пример, где получим, не гипотетически, а на практике, у меня не получилось, может плохо старался.
А, нет, влияет: как раз-таки при вставке std::unrechable компилятор перестаёт генерировать ud2, т.к. программист не только себе, но и компилятору мамой клянётся, что 3 там никак не получится. По крайней мере, у меня так вышло, может, оно и не всегда так.
SP>Причём в С++ давно нашли решение этой дилеммы. Те, кому нужна безопасность, просто обвешиваются санитайзерами и не лезут в дела других. Но конечно человек так не умеет. Ему обязательно надо рассказать остальным почему они мудаки и поступают неправильно
Я уверен, что кто-то страдает и по отсутствию автоматического приведения указателей на что угодно в указатели на что угодно, как это было в C. Уверен, что немало было по этому поводу стонов ("мамой клянусь, я знаю, что за этим void* на самом деле лежит int*, не нужно от меня требовать явного преобразования). Или по тому, что const-correctness — это прямо боль("мамой клянусь, я не буду менять объект").
И я рад, что, несмотря на эту боль, компиляторщики дали мне и ворнинг, и генерацию ud2, и другую диагностику, которой раньше не было.
Санитайзеры — сильно более другой подход, хоть и важный. Сильно влияют на характеристики производительности, на CI/CD (нужно же как-то, чтобы санитайзер у нас отработал, а клиенту поехал продукт без оного).
Здравствуйте, serg_joker, Вы писали:
_>Вы действительно хотите, чтобы для такого кода:
_>, вместо того, чтобы программа упала с криком "чувак, ты налажал!", ф-ция ShouldBackup была просто тождественно равной false? _>И потом отлаживаться сильно дальше, не понимая, какого хрена? Ясно, что в таком плоском примере всё очевидно, но обычно же оно сильно не так.
_>Неужели быстрая смерть, ровно один раз, с крайне простой диагностикой хуже, чем, программа, которая ведёт себя странно?
Я думаю меньше всего мы хотим чтобы программа падала из за любой помарки. Вот если бы там какой нибудь исскуственный интелект просчитал что вот этот конкретно невозврат повлияет дальше на критически важную часть функционирования, но нет. Но вообще критически важные части должны быть специально защищены от неверных данных или еще чего там, проверки, эксцепшионы.. В таких случаях максимум вмешательства в работу проги от тупого компилятора это выдача диагностического сообщения если есть куда выдавать. Если некуда типа ГУИ, ну пусть диалог выдаст и то не факт что это хорошо. К тому же эта конкретно ошибка проверяется на этапе компиляции/линт и выдача предупреждения тогда имеет смысл. Может даже и не предупреждения а ошибки компиляции если прогер так установил.
Здравствуйте, m2user, Вы писали:
M>И всякие относительно безобидные warnings (типа unused variable) будут ошибкой. Это неудобно. M>Я вот тоже не понимаю, почему пропущенный return не считается ошибкой компиляции.
Вообще-то, и gcc и clang выдают предупреждение в этом месте.
Здравствуйте, alpha21264, Вы писали:
A>При этом все эти const заметно захламляют код и не несут никакого смысла.
const очень помогает. Но надо не забывать, конечно, правильно размечать аргументы функций, которые она не меняет.
Причем помогает даже не от случайных ошибок, а помогает читать код. Например, когда хочешь понять, кто поднасрал в сложную структуру, внутрь функций, которые получают ее, как указатель на константу, можно не заглядывать.
Здравствуйте, qqqqq, Вы писали:
Q>А просто падать по любому поводу западло.
Моё мнение отличается. Это не "любой повод" и не "помарка", а западло — иметь культуру разработки, позволяющую пропустить этот ворнинг.
Вот специально проверил:
предупреждение об отсутствии возврата появилось в gcc 8.x (2018)
генерация кода с ud2 — gcc 13.x (2023)
Здравствуйте, serg_joker, Вы писали:
_>Когда я пришёл, то при компиляции вылазила куча предупреждений на стандартном уровне предупреждений. _>Одно из того, что я сделал первым — это выставил для всего проекта (-Wall -Werror) _>Получил в итоге ~1500 предупреждений, может и больше, не уверен.
В этом упражнении самое сложное — заручиться согласием руководства делать это упражнение.
Здравствуйте, Marty, Вы писали:
M>Я, кстати, неоднократно откушивал говнеца, когда забывал сделать возврат, и лень было разбираться в простыне варнингов, среди которых были и предупреждения о том, что нет return. А если бы вставлялась такая инструкция, то падало бы сразу и в конкретном месте, ничего бы искать не надо было
Вот за что я люблю Go, в нем нету предупреждений. Отсутствие явного return в функции, которая обещала вернуть значение, это ошибка компиляции.
Здравствуйте, serg_joker, Вы писали:
_>Допустим, по каким-то очень важным причинам мы не можем настроить проект так, чтобы он был чист с точки зрения предупреждений компилятора и мы просто увидели, что ф-ция может проваливаться в ветку без return. Хотя это само по себе вызывает у меня вопросы к коду и людям, его поддерживающим.
Это может быть опечаткой.
_>, вместо того, чтобы программа упала с криком "чувак, ты налажал!", ф-ция ShouldBackup была просто тождественно равной false? _>И потом отлаживаться сильно дальше, не понимая, какого хрена? Ясно, что в таком плоском примере всё очевидно, но обычно же оно сильно не так.
Лично я, если бы меня спросили, сильно предпочёл бы, чтобы с криком "упал" компилятор.
Хотя, вероятно, он просто вставляет UD2 во все пути, где функция с заявленным возвратом значения может выйти мимо return.
_>Имхо, детерменированно нерабочая программа лучше, чем программа, только похожая на рабочую.
Как говорит один мой знакомый, "программа, которая не работает, с только делает вид, что работает".
Pzz>Вообще-то, и gcc и clang выдают предупреждение в этом месте.
Так никто и не утверждает, что warning отстутствует.
Вопрос в том, почему это warning, а не error.
В топике писали, что компилятор не может в общем случае понять, что return нужен/или не нужен (типа std::abort где-то внутрях вызывается).
Ну пусть будет false-positive, не вижу тут большой проблемы (в C# это например не проблема).
P.S. да я знаю, что можно конкрентый warning переключить в error. Но тогда нужно руками пройтись по всем таким warning`ам и составить список того, что нужно переключить, а что оставить (unused variable)
Здравствуйте, Pzz, Вы писали:
Pzz>В этом упражнении самое сложное — заручиться согласием руководства делать это упражнение.
Я стараюсь работать в таких местах, где мне это не сложно. Пока получалось.
Ещё лучше — присоединяться к командам, где уже до меня понимали важность культуры разработки, такое тоже случалось, хоть и реже.
Там, где пока этого нет, и мне не дадут добро, я постараюсь не быть.
Здравствуйте, m2user, Вы писали:
Pzz>>Вообще-то, и gcc и clang выдают предупреждение в этом месте.
M>Так никто и не утверждает, что warning отстутствует. M>Вопрос в том, почему это warning, а не error.
По историческим причинам.
Те же самые люди, которые когда-то сделали Си, позже сделали Go, исправив в нем многие ошибки, допущенные при разработке Си. Например, в Go нет warning, есть только error.
Здравствуйте, Pzz, Вы писали:
Pzz>Вот за что я люблю Go, в нем нету предупреждений. Отсутствие явного return в функции, которая обещала вернуть значение, это ошибка компиляции.
Уверен, что если бы С++ делали сейчас или даже 20 лет назад и без груза совместимости с С, то поступили бы так же.
А так — да, ошибка компиляции сильно лучше, чем предупреждение или обвал в рантайме.
Здравствуйте, Pzz, Вы писали:
_>>Допустим, по каким-то очень важным причинам мы не можем настроить проект так, чтобы он был чист с точки зрения предупреждений компилятора и мы просто увидели, что ф-ция может проваливаться в ветку без return. Хотя это само по себе вызывает у меня вопросы к коду и людям, его поддерживающим.
Pzz>Это может быть опечаткой.
Отсутствие return, безусловно, может быть опечаткой.
Отсутствие возможности увидеть и среагировать на предупреждение (а ещё лучше заиметь ошибку компиляции по -Werror) — вот, что вызывает вопросы.
Здравствуйте, serg_joker, Вы писали:
Pzz>>В этом упражнении самое сложное — заручиться согласием руководства делать это упражнение. _>Я стараюсь работать в таких местах, где мне это не сложно. Пока получалось. _>Ещё лучше — присоединяться к командам, где уже до меня понимали важность культуры разработки, такое тоже случалось, хоть и реже.
Ну непонятно, откуда в команде, где до тебя понимали важность культуры разработки, образовалось 1500 предупреждений, стоило их в компиляторе разрешить.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну непонятно, откуда в команде, где до тебя понимали важность культуры разработки, образовалось 1500 предупреждений, стоило их в компиляторе разрешить.
Это был случай, когда культуры не было, но у меня была свобода её внедрить.
Если бы не разрешили, я бы там не работал.
Здравствуйте, alpha21264, Вы писали:
S>>Такое ощущение, что вы продолжаете жить в 1980-х. Уже к середине 1990-х такое стало моветоном.
A>Я знаю. Я действительно не стильно-модно-молодёжный.
При чём тут модность-молодёжность?
У человеческой головы ограниченная пропускная способность. И как-то глупо тратить столь ценный ресурс на то, чем вполне мог бы заняться компилятор.
Предупреждения помогают. Просто надо уметь их готовить.
