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

Но вернемся к основам. Суть этого раздела заключается в том, чтобы призвать вас использовать const_iteratorвезде, где возможно. Фундаментальный мотив для этого — применение constвсегда, когда это имеет смысл — существовал и до С++11, но в С++98 этот принцип при работе с итераторами был непрактичным. В С++11 это сугубо практический совет, а в С++14 к тому же “доведены до ума” некоторые мелочи, остававшиеся незавершенными в С++11.

• Предпочитайте использовать const_iteratorвместо iteratorтам, где это можно.

• В максимально обобщенном коде предпочтительно использовать версии функций begin, end, rbeginи прочих, не являющиеся членами.

В С++98 спецификации исключений были довольно темпераментными созданиями. От вас требовалось собрать информацию обо всех типах исключений, которые могла генерировать функция, так что при изменении реализации функции могла потребовать изменения и спецификация исключений. Изменение спецификации исключения могло нарушить клиентский код, так как вызывающий код мог зависеть от исходной спецификации исключений. Компиляторы обычно не предлагали никакой помощи в поддержании согласованности между реализациями функций, спецификациями исключений и клиентским кодом. Большинство программистов в конечном итоге сочло, что спецификации исключений в С++98 не стоят затрачиваемых на них усилий и ими лучше не пользоваться вовсе. Во время работы над С++11 было достигнуто согласие, что действительно важная информация о поведении функций в смысле исключений — это информация, может ли вообще такое исключение быть сгенерировано. Либо функция может генерировать исключение, либо гарантируется, что это невозможно. Именно эта дихотомия лежит в основе спецификаций исключений С++11, которые, по сути, заменили спецификации исключений С++98. (Спецификации исключений в стиле С++98 остаются корректными, но не рекомендуются к употреблению.) В С++11 безусловный модификатор noexceptприменяется к функциям, которые гарантированно не могут генерировать исключения.

Должна ли функция быть объявлена таким образом — вопрос проектирования интерфейса. Поведение генерирующих исключения функций представляет большой интерес для клиентов. Вызывающий код может запросить статус noexceptфункции, и результат этого запроса может повлиять на безопасность в смысле исключений или эффективность вызывающего кода. Таким образом, является ли функция объявленной как noexcept, представляет собой столь же важную часть информации, как и является ли функция-член объявленной как const. Отсутствие объявления функции как noexcept, когда вы точно знаете, что она не в состоянии генерировать исключения, — не более чем просто плохая спецификация интерфейса.

Но есть и дополнительный стимул для применения noexceptк функциям, которые не генерируют исключений: это позволяет компиляторам генерировать лучший объектный код. Чтобы понять, почему это так, рассмотрим разницу между способами, которыми С++98 и С++11 сообщают о том, что функция не может генерировать исключения. Пусть имеется функция f, которая обещает вызывающему коду, что тот никогда не получит исключения. Вот как выглядят два способа это выразить:

int f(int x) throw(); // f не генерирует исключений: С++98

int f(int x) noexcept; // f не генерирует исключений: C++11

Если во время выполнения некоторое исключение покинет f, тем самым будет нарушена спецификация исключений f. При спецификации исключений С++98 стек вызовов сворачивается [6] Обычно в русскоязычной литературе для термина stack unwinding используется перевод “разворачивание стека”. Однако это не совсем верный перевод. Вот что в переписке с редактором книги пишет по этому поводу профессор университета Иннополис E. Зуев: “ Самый частый вариант перевода — «раскрутка стека» — не просто затемняет существо дела, но просто-таки противоположен ему. При срабатывании исключения начинается процесс поиска в стеке секции (“кадра стека”, stack frame), для которой задан перехват случившегося исключения. В тексте исходной программы такой секции соответствует try-блок с catch-обработчиком, в котором задано имя случившегося исключения. И в процессе этого поиска все секции стека, для которых такой перехват не задан, из стека удаляются . Говорят еще, что производится поиск секции по всей динамической цепочке вызовов. Тем самым стек в целом сокращается, сворачивается . Таким образом, самый адекватный вариант перевода — сворачивание стека ”. Поэтому принято решение переводить stack unwinding как сворачивание стека. — Примеч. ред . до вызывающего fкода, и после некоторых действий, не имеющих значения для данного рассмотрения, выполнение программы прекращается. При спецификации исключений С++11 поведение времени выполнения несколько иное: стек только, возможно , сворачивается перед завершением выполнения программы.

Разница между сворачиванием стека и возможным сворачиванием оказывает на удивление большое влияние на генерацию кода. В случае функции, объявленной как noexcept, оптимизаторам не надо ни поддерживать стек в сворачиваемом состоянии, ни гарантировать, что объекты в такой функции будут уничтожены в порядке, обратном созданию, если вдруг такую функцию покинет исключение. Функции со спецификацией throw()не имеют такой гибкости оптимизации, как и функции без спецификаций вообще. Ситуацию можно резюмировать следующим образом:

RetType function(params) noexcept; // Наиболее оптимизируема

RetType function(params) throw(); // Менее оптимизируема

RetType function(params) ; // Менее оптимизируема

Этого одного достаточно для того, чтобы объявлять функции, о которых точно известно, что они не генерируют исключений, как noexcept.

Для некоторых функций все оказывается еще более интересным. Выдающимся примером являются операции перемещения. Предположим, что у вас имеется код С++98, использующий std::vector. Объекты типа Widgetвремя от времени добавляются в std::vector с помощью функции push_back:

std::vector vw;

…

Widget w;

… // Работа с w

vw.push_back(w); // Добавление w к vw

Предположим, что этот код отлично работает, и нет никакой необходимости изменять его для С++11. Однако вы хотите воспользоваться тем фактом, что семантика перемещения С++11 может улучшить производительность старого кода при участии типов, допускающих перемещающие операции. Вы уверены, что класс Widgetтакие операции имеет — либо потому, что вы написали их самостоятельно, либо потому, что вы убедились в осуществлении условий для их автоматической генерации (см. раздел 3.11).