Здравствуйте, 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.

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.

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

Автор: rg45
Дата: 12.01 21:59

отвечал уже на похожий вопрос.

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();

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

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

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

·>AccountType accountType = getAccountType();
·>

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

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

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

SVZ>Но только мы по-прежнему не знаем, что можно сделать с этим accountType — ни какие данные из него получить, ни какому методу его можно скормить.

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().