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

std::function&,

const std::unique_ptr&)>

derefUPLess = [](const std::unique_ptr& p1,

const std::unique_ptr& p2)

{ return *p1 < *p2; };

Важно понимать, что, даже если оставить в стороне синтаксическую многословность и необходимость повторения типов параметров, использование std::function— не то же самое, что использование auto. Переменная, объявленная с использованием autoи хранящая замыкание, имеет тот же тип, что и замыкание, и как таковая использует только то количество памяти, которое требуется замыканию. Тип переменной, объявленной как std::functionи хранящей замыкание, представляет собой конкретизацию шаблона std::function, которая имеет фиксированный размер для каждой заданной сигнатуры. Этот размер может быть не адекватным для замыкания, которое требуется хранить, и в этом случае конструктор std::functionбудет выделять для хранения замыкания динамическую память. В результате объект std::functionиспользует больше памяти, чем объект, объявленный с помощью auto. Кроме того, из-за деталей реализации это ограничивает возможности встраивания и приводит к косвенным вызовам функции, так что вызовы замыкания через объект std::functionобычно выполняются медленнее, чем вызовы посредством объекта, объявленного как auto. Другими словами, подход с использованием std::functionв общем случае более громоздкий, требующий больше памяти и более медленный, чем подход с помощью auto, и к тому же может приводить к генерации исключений, связанных с нехваткой памяти. Ну и, как вы уже видели в примерах выше, написать “ auto” — гораздо проще, чем указывать тип для инстанцирования std::function. В соревновании между autoи std::functionдля хранения замыкания побеждает auto. (Подобные аргументы можно привести и в пользу предпочтения autoперед std::functionдля хранения результатов вызовов std::bind, но все равно в разделе 6.4 я делаю все, чтобы убедить вас использовать вместо std::bindлямбда-выражения...)

Преимущества autoвыходят за рамки избегания неинициализированных переменных, длинных объявлений переменных и возможности непосредственного хранения замыкания. Кроме того, имеется возможность избежать того, что я называю проблемой “сокращений типа” (type shortcuts). Вот кое-что, что вы, вероятно, уже видели, а возможно, даже писали:

std::vector v;

…

unsignedsz = v.size();

Официальный возвращаемый тип v.size()— std::vector::size_type, но об этом знает не так уж много разработчиков. std::vector::size_typeопределен как беззнаковый целочисленный тип, так что огромное количество программистов считают, что unsignedвполне достаточно, и пишут исходные тексты, подобные показанному выше. Это может иметь некоторые интересные последствия. В 32-разрядной Windows, например, и unsigned, и std::vector::size_typeимеют один и тот же размер, но в 64-разрядной Windows unsignedсодержит 32 бита, а std::vector::size_type— 64 бита. Это означает, что код, который работал в 32-разрядной Windows, может вести себя некорректно в 64-разрядной Windows. И кому хочется тратить время на подобные вопросы при переносе приложения с 32-разрядной операционной системы на 64-разрядную?

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

autosz = 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, в которых явная типизация переменных — большая редкость. Сообщество разработчиков программного обеспечения имеет обширный опыт работы с выводом типов, и он продемонстрировал, что в такой технологии нет ничего мешающего созданию и поддержке крупных приложений промышленного уровня.