Войти
ФлеймФорумПрограммирование

C++. Auto. Добро или Зло? (4 стр)

Страницы: 13 4 5 615 Следующая »
#45
18:03, 28 июня 2019

1 frag / 2 deaths
> Я считаю, что auto это хипстерское говно, и лучше б его назвали
> std::automatically_deduce_type
хех, сразу видно больную мозоль старого плюсовика.


#46
18:53, 28 июня 2019

Kartonagnick

> если бы поциент просто не осилил ссылки-амперсанды
Не важно, что ты осилил. Важно - что видно когда читаешь код. Хорошо, если ты помнишь, что в одно рыло наговнокодил за прошлый месяц, какие функции у тебя возвращают указатели, а какие ссылки. Гораздо хуже, если это приходится кому-то читать, а уж разбираться - вообще ад.

> что в контексте ссылочной семантики, оби формы записи - монопенисуальны
Браво. Осталось только определиться, какой семантики у нас сейчас контекст.

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

#47
18:58, 28 июня 2019

Ghost2
Сейчас картонажник опять запутается, начнет истерить, материться и попадет в баню.

#48
19:22, 28 июня 2019

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

#49
21:40, 28 июня 2019

Все кто против auto должны быть против и typedef тогда уж. Ведь не кто не обязывает для тех же указателей писать

typedef SomeClassWithLongName* ShortNamePtr; 
Руководствуйтесь здравым смыслом и всё будет хорошо. Область видимости локальный переменных обычно не сильно большая и внутри реализаций, ну а коль вы полезли ковыряться в реализации написанной кем то, уж будьте добры разбиритесь что там к чему. И auto в этом деле будет меньшей из проблем. Специфические случаи когда auto используется для возврата и в параметрах шаблонах опустим :)

#50
21:52, 28 июня 2019

pahaa

> не ставят квалификаторы и семантику у переменных
Квалификаторы, семантика, много красивых слов. Основная проблема auto заключается в том, что неизвестно, какой тип будет выведен. Ну и читаемость результата тоже не очень.
А еще существует гайдлайн на mission/safety critical применение С++14 в котором запрещается (за исключением некоторых случаев) использовать auto.

#51
1:52, 29 июня 2019

Aroch
> Все кто против auto должны быть против и typedef тогда уж.
С чего бы это? typedef вводит новое имя, а auto нет.

> Ведь не кто не обязывает для тех же указателей писать
> typedef SomeClassWithLongName* ShortNamePtr;
Практически так всегда и пишу. Только немного по другому:

using ShortNamePtr = std::unique_ptr<SomeClassWithLongName>;
И дальше использую только ShortNamePtr

#52
(Правка: 2:52) 2:23, 29 июня 2019

Vlad2001_MFS
> Тут и без звезды очевидно, что obj - указатель.
> А так я не пишу.

есть такое понятие: единый стиль.
если ты указываешь семантику, то указываешь её везде.

const auto* name = getName();
auto& value = getValue();
auto* context = allocateContext();
auto* some = new Some;  

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

а вот если человек в одном случае пишет так, в другом - этак,
то потом уже другие люди, после такого творчества приходят на ГД,
и начинают ныть, что мол, auto им не понятно.

#53
2:48, 29 июня 2019

Ghost2
> Осталось только определиться, какой семантики у нас сейчас контекст.
> я уж думал, что ты обиделся на геймдев.

ты думать оказывается умеешь?
а судя по твоим ответам так сразу и не скажешь.

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

const auto& name = getName(); // 1
const auto* name = getName(); // 2

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

Ghost2
> Основная проблема auto заключается в том, что неизвестно, какой тип будет
> выведен.

приведи пример такой проблемы.

на самом деле такой проблемы не существует.

между следующими примерами кода
нет никакой принципиальной разницы:

IWidget& widget = getChild();
widget.setXY(1,1);   // <—- на практике, всем насрать, 
// какой там может быть наследник
auto& widget  = getChild();
widget.setXY(1,1);
getChild().setXY(1,1);

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

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

#54
2:51, 29 июня 2019

1 frag / 2 deaths
> Вообще язык говно, если по дефолту молчком делает копирование.
Это как раз-таки очень правильно в рамках исходной парадигмы. Говно в том, что ссылкам разрешили быть полноценным типом, который можно тайпдефить и использовать для переменных и членов, а не только для параметров функции. А из-за этого уже и полезли всякие проблемы, типа как разруливать двойные ссылки, как определять ссылка-не ссылка в деклтайпах, где копирование, и всё такое прочее. Если б принципа "любой тип - это значение" придерживались последовательно и непримиримо, то не было бы никаких проблем с копированием. Погроммист держал бы в голове простое правило - "значение копируется всегда, когда куда-нибудь пишется-читается-передаётся, кроме передачи параметра функции по ссылке", и никаких неоправданных ожиданий от поведения всяких там векторов у него бы не возникало. И, если бы ему вдруг был бы нужен вектор объектов, он бы знал, что нужно vector[SmartPtr[T]], и никак иначе.

Вообще, конечно, с соотношением lvalue и указателей накосячили ещё в Ц. Можно было сделать по-другому:
- если есть переменная T a или T a[N], то выражение a - это значение-указатель T * (для массива - на 1-й элемент),
- допускается неявный каст T * в T методом дереференса,
- для арифметики указателей - строго оператор [], возвращающий тоже T *,
- выражение &a возвращает этот указатель как intptr_t - для тех случаев, когда указатель таки нужен именно как бинарный объект.
Тогда всё получилось бы сильно проще, в языке были бы только указатели, и когда появился Ц++, в нём не пришлось бы вводить никакой шизофренично-ссылочной семантики, и он бы развивался совсем по-другому.
Но момент упустили.

#55
3:05, 29 июня 2019

Ghost2
> неизвестно, какой тип будет выведен

MyAwesomeClass& getMyAwesomeClassObject();
const auto& myLocalVariable = getMyAwesomeClassObject();
Где именно неизвестно?


Sbtrn. Devil
> в языке были бы только указатели, и когда появился Ц++, в нём не пришлось бы
> вводить никакой шизофренично-ссылочной семантики
О чём речь? Что ещё было в сях, кроме указателей?

#56
5:17, 29 июня 2019

Kartonagnick

> приведи пример такой проблемы
> на самом деле такой проблемы не существует
Лол. Не существует, ну и ладно.

pahaa

> Где именно неизвестно?
Ты имена файлов и номера строк забыл расставить.

ЗЫ. Рекомендую ознакомиться: https://www.autosar.org/fileadmin/user_upload/standards/adaptive/… uidelines.pdf

#57
8:34, 29 июня 2019

Ghost2
> Гораздо хуже, если это приходится кому-то читать, а уж разбираться - вообще ад.
  В нормальной IDE узнать тип переменной не сложнее, чем навести курсор на слово. Причём это работает даже если само определение где-то несколькими экранами выше или вообще в другом файле. Прикинь, да?

Kartonagnick
> есть такое понятие: единый стиль.
  Ой уж вот кому-кому, а точно не крестовикам загонять за единый стиль.

#58
(Правка: 9:26) 9:25, 29 июня 2019

Пока выдумаешь политику правильного использования ауто, уже новое убогое апи выйдет, и движок придётся переписывать.

Там пропозал на смарт гоуту не подоспел ещё? Чтобы не гоуту, если девелопер не хочет.
#59
10:27, 29 июня 2019

Zefick

> В нормальной IDE узнать тип переменной не сложнее
Уйди ты со своими нормальными IDE. Я хочу смотреть на код и видеть его проблемы без возюканья мышкой по экрану. Это называется читаемость.

> Причём это работает даже если само определение
Воистину великое достижение. Тебя бы давно уволили давно без этого, а в твоём резюме наверное гордо красуется умение пользоваться Eclipse (или еще каким-нибудь подобным говном). Ведь нужно писать код так, чтобы разобраться что там написано можно было непременно при поищи чего-то.

Страницы: 13 4 5 615 Следующая »
ФлеймФорумПрограммирование