Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14 - [19]

Применение auto гарантирует, что вам не придется этим заниматься:

auto sz = v.size(); // Тип sz – std::vector::size_type

Все еще не уверены в разумности применения auto? Тогда рассмотрите следующий код.

std::unordered_map m;
…
for (const std::pair& p: m) {
 … // Что-то делаем с p
}

Выглядит вполне разумно… но есть одна проблема. Вы ее не видите?

Чтобы разобраться, что здесь не так, надо вспомнить, что часть std::unordered_map, содержащая ключ, является константной, так что тип std::pair в хеш-таблице (которой является std::unordered_map) вовсе не std::pair, а std::pair. Но переменная p в приведенном выше цикле объявлена иначе. В результате компилятор будет искать способ преобразовать объекты std::pair (хранящиеся в хеш-таблице) в объекты std::pair (объявленный тип p). Этот способ — создание временного объекта типа, требуемого p, чтобы скопировать в него каждом объект из m с последующим связыванием ссылки p с этим временным объектом. В конце каждой итерации цикла временный объект уничтожается. Если этот цикл написан вами, вы, вероятно, будете удивлены его поведением, поскольку почти наверняка планировали просто связывать ссылку p с каждым элементом в m.

Такое непреднамеренное несоответствие легко лечится с помощью auto:

for (const auto& p : m) {
 … // Как и ранее
}

Это не просто более эффективно — это еще и менее многословно. Кроме того, этот код имеет очень привлекательную особенность — если вы возьмете адрес p, то можете быть уверены, что получите указатель на элемент в m. В коде, не использующем auto, вы получите указатель на временный объект — объект, который будет уничтожен в конце итерации цикла.

Два последних примера — запись unsigned там, где вы должны были написать std::vector::size_type, и запись std::pair там, где вы должны были написать std::pair, — демонстрируют, как явное указание типов может привести к неявному их преобразованию, которое вы не хотели и не ждали. Если вы используете в качестве типа целевой переменной auto, вам не надо беспокоиться о несоответствиях между типом объявленной переменной и типом инициализирующего ее выражения.

Таким образом, имеется несколько причин для предпочтительного применения auto по сравнению с явным объявлением типа. Но auto не является совершенным. Тип для каждой переменной, объявленной как auto, выводится из инициализирующего ее выражения, а некоторые инициализирующие выражения имеют типы, которые не предполагались и нежелательны. Условия, при которых возникают такие ситуации, и что при этом можно сделать, рассматриваются в разделах 1.2 и 2.2, поэтому здесь я не буду их рассматривать. Вместо этого я уделю внимание другому вопросу, который может вас волновать при использовании auto вместо традиционного объявления типа, — удобочитаемость полученного исходного текста.

Для начала сделайте глубокий вдох и расслабьтесь. Применение auto — возможность, а не требование. Если, в соответствии с вашими профессиональными представлениями, ваш код будет понятнее или легче сопровождаемым или лучше в каком-то ином отношении при использовании явных объявлений типов, вы можете продолжать их использовать. Но имейте в виду, что С++ — не первый язык, принявший на вооружение то, что в мире языков программирования известно как вывод типов (type inference). Другие процедурные статически типизированные языки программирования (например, С#, D, Scala, Visual Basic) обладают более или менее эквивалентными возможностями, не говоря уже о множестве статически типизированных функциональных языков (например, ML, Haskell, OCaml, F# и др.). В частности, это объясняется успехом динамически типизированных языков программирования, таких как Perl, Python и Ruby, в которых явная типизация переменных — большая редкость. Сообщество разработчиков программного обеспечения имеет обширный опыт работы с выводом типов, и он продемонстрировал, что в такой технологии нет ничего мешающего созданию и поддержке крупных приложений промышленного уровня.

Некоторых разработчиков беспокоит тот факт, что применение auto исключает возможность определения типа при беглом взгляде на исходный текст. Однако возможности IDE показывать типы объектов часто устраняют эту проблему (даже если принять во внимание обсуждавшиеся в разделе 1.4 вопросы, связанные с выводом типов в IDE), а во многих случаях абстрактный взгляд на тип объекта столь же полезен, как и точный тип. Зачастую достаточно, например, знать, что объект является контейнером, счетчиком или интеллектуальным указателем, не зная при этом точно, каким именно контейнером, счетчиком или указателем. При правильном подборе имен переменных такая абстрактная информация о типе почти всегда оказывается под рукой.

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