Re[6]: auto - минусы использования? - C/C++

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Минус вижу один — код хуже читается без IDE.

Лично для себя в жаве вывел принцип. Если без IDE типа очевиден, то можно писать var. Если не очевиден — то надо указывать тип. К примеру

var n = 1;
var l = new ArrayList<String>();
var person = personRepository.get(personId);

Не вижу, почему бы это правило работало хуже в любом другом языке программирования.

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Минус очевидный — не видишь типа.
Без навороченной IDE не сможешь и шагу ступить.
А иной раз и сама IDE может не показать корректный тип.

Если тип очевиден, то auto — хороший способ сократить километровую запись, к примеру, какие-нить итераторы у стандартных контейнеров.
Но иногда полезно иметь тип перед глазами.

Добавлю: есть ещё различные интерфейсы, наследование.
Иногда требуется получить конкретный тип.

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Сам ответь на вопрос, какой тип будет у переменной:

auto var = func();

какой ???

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

V>Сам ответь на вопрос, какой тип будет у переменной:

V>auto var = func();
V>

какой ???

На это тебе сейчас возразят, что у func должно быть красноречивое название, чтобы было ясно, что она возвращает.
Иногда это, действительно, работает.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>На это тебе сейчас возразят, что у func должно быть красноречивое название, чтобы было ясно, что она возвращает.
SVZ>Иногда это, действительно, работает.

еще могут сказать что у них IDE и им плевать на тех, кто код ревьюит

V>>Сам ответь на вопрос, какой тип будет у переменной:

V>>auto var = func();
V>>

какой ???

SVZ>На это тебе сейчас возразят, что у func должно быть красноречивое название, чтобы было ясно, что она возвращает.

Тогда можно задать дополнительный вопрос — как правильно переименовать функцию getUserId() в красноречивое название, чтобы было ясно, что она возвращает?

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

пытаюсь указывать тип в ляибдах. Там IDE входит в ступор и не делает подсказку по методам. Н-р:

std::vector<std::string> str;
std::views::transform(str_vec, [](const auto& str) { return str.size(); });

А вообще auto — вещь очень полезная при рефакторинге. Тип поменялся, а код "выглядит как живой". Только чуть-чуть поменял и уже всё работает. Так что даже когда тип не очевиден, это не повод отказываться от auto.

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

S>>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?
V>Сам ответь на вопрос, какой тип будет у переменной:

V>auto var = func();
V>

какой ???

А зачем знать тип переменной?

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Через полгода обрастёшь шерстью и превратишься во фронтэндера.

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

BFE>А зачем знать тип переменной?

Например затем, что бы знать какой из хуллиардов перегруженных методов вызовется здесь:

auto var = func();

overloads(var);

Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?

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

vsb>

vsb>var n = 1;
vsb>var l = new ArrayList<String>();
vsb>var person = personRepository.get(personId);
vsb>

Ну не знаю. По мне так var безусловно уместен только во второй строчке.

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

V> Например затем, что бы знать какой из хуллиардов перегруженных методов вызовется здесь:
V>

V> auto var = func();
V> overloads(var);
V>

Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?
В общем случае конечно фигня. А в таком случае какие вопросы?

auto user = getUser();
auto account = getAccount();
remove(user);
remove(account);

avalon/3.0.0

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

K>Тогда можно задать дополнительный вопрос — как правильно переименовать функцию getUserId() в красноречивое название, чтобы было ясно, что она возвращает?

Она возвращает User ID. Какой конкретно сейчас базовый тип у этого идентификатора — целое 32 бита (знаковое, беззнаковое?) или строчка (GUID, UUID, хэш в base64) или ещё что — не так уж и важно. Если это вдруг играет роль — надо пересмотреть логику в целом. Чем-то явно пахнет.

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

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

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

·>В общем случае конечно фигня. А в таком случае какие вопросы?
·>

·>auto user = getUser();
·>auto account = getAccount();
·>remove(user);
·>remove(account);
·>

В таком норм, но ведь предполагается использовать auto абсолютно везде, во всех случаях. Если мы пишем код и помним контекст в голове всё кажется понятным. Если читать незнакомый код, то auto усложняет задачу понимания в разы. Плюс, автоматическая замена типа переменной на auto сделает почти любую программу, сложнее "hello word", некорректной, т.к. в С++ очень важны нюансы связанные с типами. Человеку который еще не знаком с кодом и хочет разобраться, важно понимать, что типы могут делать, а что нет. IDE помогает слабо, особенно в С++.

BFE>>А зачем знать тип переменной?

V>Например затем, что бы знать какой из хуллиардов перегруженных методов вызовется здесь:
V>

auto var = func();

overloads(var);

Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?

А если бы было overloads(func())? 🤡

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

V>>

σ>auto var = func();

σ>overloads(var);
σ>

Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?

σ>А если бы было overloads(func())? 🤡

Я думаю, что это просто немного разные сценарии. По сложности разные. В последнем случае временный объект (ну или ссылка — не суть) создается для того, чтоб выполнить над ним ровно одно действие. Это действительно простой случай и без знания типа объекта, наверное, можно легко обойтись в большинстве случаев. В предыдущем же примере, как я понимаю, подразумевается, что над объектом могут выполняться какие-то еще другие действия, прежде чем он будет передан в функцию overloads. Вероятно также, что этот объект не будет единственным в этом фрагменте программы. То есть, предыдущй пример в целом сложнее и явное указание типов действительно облегчает чтение кода, тут я полностью согласен.

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

V> В таком норм, но ведь предполагается использовать auto абсолютно везде, во всех случаях. Если мы пишем код и помним контекст в голове всё кажется понятным. Если читать незнакомый код, то auto усложняет задачу понимания в разы. Плюс, автоматическая замена типа переменной на auto сделает почти любую программу, сложнее "hello word", некорректной, т.к. в С++ очень важны нюансы связанные с типами. Человеку который еще не знаком с кодом и хочет разобраться, важно понимать, что типы могут делать, а что нет. IDE помогает слабо, особенно в С++.
В целом согласен. Это вообще философия и субъективно. Кому-то "auto userId" хватает, а кому-то хочется знаать, что это тип uuid, а кому-то ещё и захочется узнать какой версии uuid. Можно и типы указывать и даже венгерскую нотацию, но всё равно можно написать так, что будет нихрена неясно даже с IDE

В общем, любую идею можно свести к абсурду. Так что топик в топку.

avalon/3.0.0

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

vsb>>

vsb>>var n = 1;
vsb>>var l = new ArrayList<String>();
vsb>>var person = personRepository.get(personId);
vsb>>

_>Ну не знаю. По мне так var безусловно уместен только во второй строчке.

Ну в первой будет int. Ладно, за С++ говорить не буду, там в этих целочисленных типах чёрт ногу сломит, в жаве в этом плане всё проще. В третьем будет тип Person. Предполагается, что человек, читающий код, хоть какое-то представление о структуре приложения имеет. Если там будет НЕ тип Person, тогда, конечно, надо указать (а может быть и переписать что-то).

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

V>>>Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?
σ>>А если бы было overloads(func())? 🤡

R>Я думаю, что это просто немного разные сценарии. По сложности разные. В последнем случае временный объект (ну или ссылка — не суть) создается для того, чтоб выполнить над ним ровно одно действие. Это действительно простой случай и без знания типа объекта, наверное, можно легко обойтись в большинстве случаев. В предыдущем же примере, как я понимаю, подразумевается, что над объектом могут выполняться какие-то еще другие действия, прежде чем он будет передан в функцию overloads. Вероятно также, что этот объект не будет единственным в этом фрагменте программы. То есть, предыдущй пример в целом сложнее и явное указание типов действительно облегчает чтение кода, тут я полностью согласен.

Эдак можно и про виртуальные функции сказать:

class SomeBaseClass { public: virtual auto overloads() -> void = 0; };

SomeBaseClass* var = func();
var->overloads();

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

BFE>Эдак можно и про виртуальные функции сказать:
BFE>

BFE>class SomeBaseClass { public: virtual auto overloads() -> void = 0; };

BFE>SomeBaseClass* var = func();
var->>overloads();
BFE>

BFE>

Признаться, я не очень понял. Что именно можно сказать и что должен был продемонстрировать данный пример?

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

r> Признаться, я не очень понял. Что именно можно сказать и что должен был продемонстрировать данный пример?
Да то же самое: "Какой, хотя бы из двух (определённых по-разному в наследниках SomeBaseClass), overloads() вызовется здесь? А если я третий добавлю?"
Тут даже хуже — вместо compile-time выбора может быть run-time.

avalon/3.0.0

V>>>

σ>>auto var = func();

σ>>overloads(var);
σ>>

Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?

σ>>А если бы было overloads(func())? 🤡

R>Я думаю, что это просто немного разные сценарии. По сложности разные. В последнем случае временный объект (ну или ссылка — не суть) создается для того, чтоб выполнить над ним ровно одно действие. Это действительно простой случай и без знания типа объекта, наверное, можно легко обойтись в большинстве случаев.

Каким образом это упрощает понимание какой из overloads вызовется?

R> В предыдущем же примере, как я понимаю, подразумевается, что над объектом могут выполняться какие-то еще другие действия

Функция будет разная выбираться, в зависимости от того, какие между auto var = func(); и verloads(var); «другие действия», что ли?

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

σ>Каким образом это упрощает понимание какой из overloads вызовется?

Никаким. Иногда, даже зная тип, фиг поймешь, какая должна подхватиться перегрузка, приходится отладчик запускать.

σ>Функция будет разная выбираться, в зависимости от того, какие между auto var = func(); и verloads(var); «другие действия», что ли?

Нет, конечно. Я просто пытался высказать мысль, что чем сложнее код, тем более востребована явная спецификация типов для его понимания. Прямой связи с резолвингом перегрузок нет.

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

r>> Признаться, я не очень понял. Что именно можно сказать и что должен был продемонстрировать данный пример?
·>Да то же самое: "Какой, хотя бы из двух (определённых по-разному в наследниках SomeBaseClass), overloads() вызовется здесь? А если я третий добавлю?"
·>Тут даже хуже — вместо compile-time выбора может быть run-time.

А, понял теперь. Нет, явное указание типа в данном случае не поможет, конечно же, я вот тут отвечал уже на похожий вопрос.

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

когда читаешь чужой код, бывает нихуя не понятно, какой тип имеется в виду

(простите, пьян)

По заголовку подумал речь о недостатках автомобилей, к примеру в городе.
А в c++, знать класс переменной на самом деле полезно а с учетом тех самых IDE, на которые тут все кивают, вставлять их вовсе и не затруднительно. А если автов в коде дохрена — то вообще мало что понятно что там и зачем. Помнится работал я в проекте, где в стандарте языка было написано что то типа авто-супер вещь, используйте где только можно вместо классов и типов. Вот это было даааааа.... Мало того Вижуал Асист реально напрягался, по моему пропускал немало переменных при поиске обьектов нужного класса и рефактоинге. По моему в c++ тенденция — как добавить в язык как можно больше хренотеней чтобы вообще никто не мог разобрался. Обфускация на уровне языка, короч.

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Предпочитаю явно указывать тип в си++. А using в помощь

offtop: Что странно, не использую type hints в php. Или очень редко

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

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

vsb>>>

vsb>>>var n = 1;
vsb>>>var l = new ArrayList<String>();
vsb>>>var person = personRepository.get(personId);
vsb>>>

_>>Ну не знаю. По мне так var безусловно уместен только во второй строчке.

vsb>В третьем будет тип Person.

скорее Optional<Person>. Но даже в этом случае я бы явно тип не указывал.

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

vsb>>>>

vsb>>>>var n = 1;
vsb>>>>var l = new ArrayList<String>();
vsb>>>>var person = personRepository.get(personId);
vsb>>>>

_>>>Ну не знаю. По мне так var безусловно уместен только во второй строчке.

vsb>>В третьем будет тип Person.

SP>скорее Optional<Person>. Но даже в этом случае я бы явно тип не указывал.

Optional<Person> я бы назвал personOpt. Но в целом это зависит от соглашений в проекте. У меня get всегда возвращает существующую сущность, а query возвращает List/Optional. Опять же предполагаем, что читатель этого кода не в первый раз видит этот проект (что, конечно, тоже допущение, но всё же где-то должны быть рамки).

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

может вернуть копию объекта вместо итератора в случае auto it : someContainter;

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>На это тебе сейчас возразят, что у func должно быть красноречивое название, чтобы было ясно, что она возвращает.
SVZ>Иногда это, действительно, работает.
Еще возразим, что имя переменной должно быть осмысленным. Согласись, что это уже лучше смотрится.

auto accountType = getAccountType();

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

vsb>Не вижу, почему бы это правило работало хуже в любом другом языке программирования.
Для численных типов в плюсах лучше явно указывать тип: потом меньше явных преобразований типов для избежания предупреждений.

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

V>Например затем, что бы знать какой из хуллиардов перегруженных методов вызовется здесь:
V>

V>auto var = func();

V>overloads(var);
V>

Какой, хотя бы из двух, overloads() вызовется здесь? А если я третий добавлю?
А если там не статический, а динамический полиморфизм?
Даже в случае статического полиморфизма к определению корректной overloads без IDE сложно.

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

SVZ>>На это тебе сейчас возразят, что у func должно быть красноречивое название, чтобы было ясно, что она возвращает.
SVZ>>Иногда это, действительно, работает.

S>Еще возразим, что имя переменной должно быть осмысленным. Согласись, что это уже лучше смотрится.
S>

S>auto accountType = getAccountType();
S>

Но только мы по-прежнему не знаем, что можно сделать с этим accountType — ни какие данные из него получить, ни какому методу его можно скормить.
Это хорошо тому, кто с этой частью проекта хорошо знаком и представляет, что возвращает getAccountType.

Ну и потенциальные ошибки — например, видя тип можно сразу среагировать на передачу по значению, вместо ссылки.
А тут пёс его знает. То ли accountType это енум, то ли интерфейс, то ли разлапистая структура

Без IDE шагу не ступить.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ> S>

SVZ> S>auto accountType = getAccountType();
SVZ> S>

SVZ> Но только мы по-прежнему не знаем, что можно сделать с этим accountType — ни какие данные из него получить, ни какому методу его можно скормить.
SVZ> Это хорошо тому, кто с этой частью проекта хорошо знаком и представляет, что возвращает getAccountType.
Ок, допустим. А если написать как

AccountType accountType = getAccountType();

Сразу всё станет понятно??

avalon/3.0.0

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

SVZ>> Но только мы по-прежнему не знаем, что можно сделать с этим accountType — ни какие данные из него получить, ни какому методу его можно скормить.
SVZ>> Это хорошо тому, кто с этой частью проекта хорошо знаком и представляет, что возвращает getAccountType.
·>Ок, допустим. А если написать как
·>

·>AccountType accountType = getAccountType();
·>

·>Сразу всё станет понятно??

Станет чуть больше информации. Да, AccountType может оказаться чем угодно.
Но зато по имени я могу сделать поиск и посмотреть использование, даже если нет IDE под рукой (или она не тянет).
Иной раз банальный Alt+F7 в ТоталКомандере удобнее, чем поиск по файлам или референсам в MSVS.

AccountType accountType = getAccountType();

А так знаете? По-моему, с auto тут лучше.

SVZ>Это хорошо тому, кто с этой частью проекта хорошо знаком и представляет, что возвращает getAccountType.
Думаю, что дело не столько в знании проекта, сколько в нормальном наименовании функций и переменных. Не агитирую за повсеметсное auto, но очень часто оно уместно.

SVZ>Ну и потенциальные ошибки — например, видя тип можно сразу среагировать на передачу по значению, вместо ссылки.
SVZ>А тут пёс его знает. То ли accountType это енум, то ли интерфейс, то ли разлапистая структура

SVZ>Без IDE шагу не ступить.
Вот. Ч. и т.д.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ> Станет чуть больше информации. Да, AccountType может оказаться чем угодно.
SVZ> Но зато по имени я могу сделать поиск и посмотреть использование, даже если нет IDE под рукой (или она не тянет).
Это да. Если IDE не тянет, то значит или код, или иде, или яп в топку.

SVZ> Иной раз банальный Alt+F7 в ТоталКомандере удобнее, чем поиск по файлам или референсам в MSVS.
Так тут важнее то как переменная accountType используется ниже. Это и стоит глядеть. В крайнем случае можно заглянуть в сигнатуру getAccountType().

avalon/3.0.0

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

vsb>Optional<Person> я бы назвал personOpt.

фишка rust здесь весьма кстати:

let person = personRepository.get(personId);
if let Some(person) = person {
    ...
}

кстати, интересно, в других языках что мешает переопределить имя под другой тип? Н-р:

Year parseYear(std::string_view year){
    auto year = parse<int>(year);
    return Year{ year };
}

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

vsb>Ну в первой будет int. Ладно, за С++ говорить не буду, там в этих целочисленных типах чёрт ногу сломит, в жаве в этом плане всё проще. В третьем будет тип Person.
И зачем гадать, когда как написать "int" было ничуть не сложнее, а "Person" немногим сложнее, а выглядело бы гораздо аккуратнее и просто опрятнее.

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

·>В общем случае конечно фигня. А в таком случае какие вопросы?
·>

·>auto user = getUser();
·>auto account = getAccount();
·>remove(user);
·>remove(account);
·>

Тогда обсуждение теряет смысл

remove(getUser());
remove(getAccount());

Понятно, что может быть ситуация, когда оно неравнозначно, но это будет уже из желания пофлеймить

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

S>

S>AccountType accountType = getAccountType();
S>

S>А так знаете? По-моему, с auto тут лучше.

Вариант с AccountType удобнее — если надо найти этот тип и понять, что этот тип из себя представляет и что с ним можно делать.

S>Думаю, что дело не столько в знании проекта, сколько в нормальном наименовании функций и переменных. Не агитирую за повсеметсное auto, но очень часто оно уместно.

Наименование нормальное, конечно же, никто не отменял, но разобраться будет быстрее, легче и проще —
если вместо auto есть конкретный тип.

Исключение из данного правила: различные итераторы в контейнерах, тем более если данные итераторы используются только локально.

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

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Помимо уже много раз упомянутой читаемости, также падает redundancy. Что в большинстве случаев не проблема, а даже плюс, особенно в generic коде.
Но в некоторых случаях нужно именно ограничение допустимого типа (или набора совместимых типов), чтобы повысить надёжность (убрав duck-typing) в свете возможных изменений upstream компонентов.

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

SP>кстати, интересно, в других языках что мешает переопределить имя под другой тип? Н-р:

Я не знаю ни одного языка кроме раста, где можно переопределять переменные в том же блоке видимости. В некоторых — можно во вложенных блоках, но обычно при этом печатается предупреждение.

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

_>Ну не знаю. По мне так var безусловно уместен только во второй строчке.

Почему не в 1-й?

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Но только мы по-прежнему не знаем, что можно сделать с этим accountType — ни какие данные из него получить, ни какому методу его можно скормить.
SVZ>Это хорошо тому, кто с этой частью проекта хорошо знаком и представляет, что возвращает getAccountType.

Так где-то рядом этот тип как-то используется, по контексту будет ясно. Сам по себе он не интересен.

SVZ>Ну и потенциальные ошибки — например, видя тип можно сразу среагировать на передачу по значению, вместо ссылки.
SVZ>А тут пёс его знает. То ли accountType это енум, то ли интерфейс, то ли разлапистая структура

SVZ>Без IDE шагу не ступить.

А что ты с этим типом делать собрался? Я думал, речь о чтении кода, а если пишешь, то ты и так знаешь, зачем ты этот тип запрашивал, и что с ним собираешься делать.

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

SVZ>>А тут пёс его знает. То ли accountType это енум, то ли интерфейс, то ли разлапистая структура

SVZ>>Без IDE шагу не ступить.

УП>А что ты с этим типом делать собрался? Я думал, речь о чтении кода, а если пишешь, то ты и так знаешь, зачем ты этот тип запрашивал, и что с ним собираешься делать.

Ну да, основные проблемы возникают, если код писал не ты. Особенно когда новый человек приходит в проект.

	От:	Shmj
	Дата:	12.01.23 07:28
	Оценка:

	От:	vsb
	Дата:	12.01.23 07:34
	Оценка:	+2

	От:	Stanislav V. Zudin
	Дата:	12.01.23 07:39
	Оценка:	+5

От:	Videoman	https://hts.tv/
Дата:	12.01.23 07:58
Оценка:	+4

	От:	Stanislav V. Zudin
	Дата:	12.01.23 08:07
	Оценка:	+3

	От:	night beast
	Дата:	12.01.23 08:09
	Оценка:	6 (1) +1

От:	netch80	http://netch80.dreamwidth.org/
Дата:	12.01.23 09:56
Оценка:	+1

	От:	Evgeny.Panasyuk
	Дата:	14.01.23 07:21
	Оценка:

	От:	ути-пути
	Дата:	15.01.23 19:52
	Оценка:

	От:	qqqqq
	Дата:	13.01.23 00:33
	Оценка:

От:	Sm0ke	ksi
Дата:	13.01.23 02:36
Оценка:

	От:	sergii.p
	Дата:	13.01.23 11:55
	Оценка:	+1

	От:	mike_rs
	Дата:	13.01.23 13:42
	Оценка: