NekZА вообще, к чему эти непотребства, когда есть auto ?вот зачем учить человека плохому? Человек правильно делает, использует using. Не надо тут использовать auto.

Anatoly MoskovskyЯ напоминаю, что auto (как и любые другие фичи языка) было внесено в язык единогласно всем комитетом по стандарту.И очень классно сделали. Потому без auto некоторые вещи невозможно сделать в шаблонах или на порядок труднее, чем с auto. И это не значит, что надо ставить его везде, где можно: auto нужен там, где вы не можете явно выписать тип. Где можете - там выписывайте, используйте using, если нужно .
NekZКак и во время добавления классов в C, история-то повторяется.Ты не разобрался в вопросе, а сделал вывод.
NekZА вот auto в range-based loop'е очень даже удобен. Не нужно тебе конкретно знать что хранится в контейнере и не придётся менять код ещё в одном месте при смене типа элементов, хранящихся в контейнере.возьми using, тебе тоже не придётся менять код ещё в одном месте. Зато в случае, если ты поменяешь что-то в контейнере, using тебе об этом напомнит, а auto нет. Не поленись, напиши один раз using, это сэкономит время тебе и твоим коллегам в будущем, при отладке и просто чтении кода.

MasterZivПочему бы для объявления типа элемента в цикле range for не использовать auto?потому что там явно можно указать тип.

читать код с auto - неудобно.
и на этом форуме и на других я видел много ошибок, связанных с auto, как правило потому что вывод типов программиста и вывод типов компилятора отрабатывают по-разному , т.е. проблема не в auto, проблема в человеках. Где-то было даже примитивное auto x = u, где u - было выражение, возвращающее unsigned int, а автор работал с ним, как с int. Думал, что это int. И три страницы поиска ошибки. А ведь, блин, int написать короче, чем auto! Это уже пагубная привычка, друзья

NekZusing чего? Элемента? Или полностью всего контейнера?если я работаю с каким-то типом, я завожу два-три, под сам тип(shared_ptr<T>), под контейнер и под итератор. При этом тип упоминается 1 раз.

NekZЕсли первое, то вопрос всё равно останется, и если мне из эстетических соображений захочется поменять само имя using'а, то придётся менять его не только в контейнере, но ещё и в каждом последующем цикле, который итерируется по этому контейнеру.ну это как-то странно, что твои эстетические соображения меняются так часто, что тебе становится это проблемой. Обычно, если ты работаешь в команде (да и один тоже, как я, например) вы приходите к некоторым соглашениям по нотации и стилю кода, так? И в течении всего проекта это никак не меняется.
NekZСовременные IDE давно умеют показывать типда, осталось дождаться, когда они за нас ещё программы писать будут. Ценность программиста определяется не только тем, что он умеет пользоваться мышкой, но больше тем, что он понимает, что и зачем он делает. Я, например:
1. Понимаю, зачем добавлен auto
2. Вижу по форумам, что возникает довольно много (глупых) ошибок из-за того, что людям лень писать тип.
И у всех у них IDE, который мышкой показывает тип auto. Проблема не в IDE, проблема в людях. Я не говорю, что нельзя, я говорю, что лучше так не делать, потому что чревато ошибками.
NekZМало того, неправильное использование числовых типов, как в том случае, ведёт к предупреждениям от компилятора и даже IDE, и не надо говорить, что их никто не читает.я читаю. Но вот в случае auto i = u, i--; предупреждения не будет, и программа выполнит то, что программист написал, а не то, что он подумал

NekZВот именно от подобного бойлерплейта и стараются избавляться в новых стандартах.Не надо от этого избавляться. Я завёл свои прототипы, и смотрю в код, я сразу вижу, где какие типы. Это сильно отличается от того, когда стоят auto, и тебе приходится смотреть вправо, чтобы провести парсинг в голове. Это, может, и полезно для ума, да :) Но неудобно.

Я пишу "два-три" - это плюс тип контейнера и итератора. Сам тип упоминается в using-ах один раз. Я могу в коде писать vector<U> или vector<U>::iterator, где U - это using that_type = ..., а могу использовать дополнительные using-и. Я их один раз определил, я всегда по нотации пойму, что это. И занимает оно 3-6 символов в среднем. И в том и в другом случае, если мне надо поменять тип объекта, я делаю это в одном месте.

NekZБолее того Вандевурд в докладе на C++ Russia 2018 показывал сколько ещё хотят навернуть компайл-тайм фич для кодогенерации на основе информации о типе аля meta_type. Язык в языке образуется. Выглядит как адЪ, но это современные тенденции и нужно принимать их, если не пропозишь в комитет, постоянно борясь с этим новым извратом.А можно на это где-то посмотреть?
Шаблоны - тоже язык в языке, но очень удобно.

NekZА нотации здесь нипричём, может, мне просто имя не понравилось, не отражающее сути типа. Ведь бывает же такое, в процессе рефакторинга?Бывает, но это не бывает при каждом рефакторинге, так ведь? 1-2 раза за проект это нормально. Больше - надо серьёзно задуматься :)

NekZЕсли можно автоматизировать какую-то рутинную часть разработки, разгрузив голову, то почему это не доверить автоматическим средствам, которые меньше допускают ошибок, нежели сам человек?
auto - это не совсем автоматизация. Это означает, что ты доверяешь вывод типов компилятору. И это не гарантирует, что компилятор выведет то, что ты подразумеваешь. Автоматизация, это когда компилятор или IDE или раб делают именно то, что ты подразумеваешь. У меня есть тул, который, по комбинации кнопок вставляет в код шаблон конструкции или большое ключевое слово целиком, или выполняет ряд каких-то действий - вот это автоматизация, оно делает именно то, что я подразумеваю, поэтому ошибок тут нет.

NekZВедь, куда лучше, программировать, а не решать постоянно технические проблемы в борьбе с инструментом, держать их все в голове.Да, для этого есть using.
И, да, лучше программировать, чем постоянно по коду лазить и вспоминать, какой тип у этого auto, а какой у этого. Ладно, когда это for(:), а когда это f()? И мне, например, не хочется каждый раз мышой подсвечивать сигнатуру.

я просто хочу донести свою мысль.
auto создавалось для случаев, когда сделать вывод типов без auto нельзя . И это хорошо.
А его используют везде , где только можно. И это плохо.
Суть программирования - заменить много действий одним. Для этого должен существовать изоморфизм между кодом и наименованиями. Так вот повсеместное использование auto слегка рвёт этот принцип.

NekZТак и в случае без auto тоже предупреждения не будет :-)А если так:
NekZВыкрутить уровень предупреждений на максимум, настроить тулзины, линтеры от clang'а (хотя бы на уровне CI)то будет :)