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

[7].

Функции swap являются еще одним случаем, когда модификатор noexcept особенно желателен. Функция swap является ключевым компонентом множества реализаций алгоритмов STL и обычно использует операторы копирующего присваивания. Ее широкое применение делает оптимизацию на основе noexcept особенно важной. Интересно, что то, является ли функция swap в стандартной библиотеке noexcept, иногда зависит от того, являются ли таковыми функции swap, определенные пользователями. Например, объявления swap в стандартной библиотеке для массивов и std::pair имеют следующий вид:

template
void swap(T (&а)[N], // См. ниже
 T (&b)[N]) noexcept(noexcept(swap(*a, *b)));

template
struct pair {
 …
 void swap(pair& p) noexcept(noexcept(swap(first, p.first)) &&
                             noexcept(swap(second, p.second)));
 …
};

Эти функции являются условноnoexcept: являются ли они noexcept-функциями, зависит от того, являются ли таковыми инструкции в конструкции noexcept. Для двух заданных массивов Widget, например, их обмен с помощью функции swap будет считаться noexcept только в том случае, если таковыми будут операции обмена отдельных элементов; т.e. если функция swap для Widget объявлена как noexcept. Таким образом, автор функции swap класса Widget определяет, будет ли операция обмена массивов Widget рассматриваться как noexcept. Это, в свою очередь, определяет, будут ли таковыми другие операции обмена, такие как swap для массива массивов Widget. Аналогично, является ли операция swap двух объектов std::pair, содержащих Widget, не генерирующей исключений, зависит от того, является ли таковой операция swap для Widget. Тот факт, что обмен высокоуровневых структур данных в общем случае может быть noexcept, только если таковым является обмен их более низкоуровневых составляющих, должен мотивировать вас объявлять функции swap как noexcept везде, где только это возможно.

Я надеюсь, вы достаточно заинтересовались возможностями оптимизации, которые предоставляет noexcept. Увы, должен умерить ваш энтузиазм. Оптимизация важна, но корректность важнее. В начале этого раздела я отмечал, что noexcept является частью интерфейса функции, так что вы должны объявлять функцию как noexcept, только если вы готовы обеспечивать это свойство в течение длительного срока. Если вы объявите функцию как noexcept, а позже измените ваше решение, то ваши перспективы окажутся невеселыми. Удаление noexcept из объявления функции (т.e. изменение ее интерфейса) ведет к риску нарушения клиентского кода. Можно также изменить реализацию так, что генерация исключения будет возможна, не меняя при этом (теперь уже некорректную) спецификацию исключений. В этом случае, если исключение попытается покинуть вашу функцию, программа завершит работу. Вы можете также подчиниться существующей реализации, забыв о своем желании ее изменить. Ни один из перечисленных вариантов привлекательным не выглядит.

Дело в том, что большинство функций нейтральны по отношению к исключениям. Такие функции сами по себе исключений не генерируют, но это могут делать функции, вызываемые ими. Когда такое происходит, нейтральная функция позволяет сгенерированному исключению пройти дальше, к обработчику, находящемуся выше по цепочке вызовов. Нейтральные по отношению к исключениям функции никогда не являются noexcept, поскольку их могут покидать такие “проходящие” исключения. Поэтому большинство функций совершенно корректно не используют спецификацию noexcept.

Некоторые функции, однако, имеют естественные реализации, которые не генерируют никаких исключений, а еще некоторое их количество (в основном операции перемещения и обмена), будучи noexcept, могут дать столь значительный выигрыш, что их стоит реализовывать как noexcept, насколько это возможно[8]. Когда вы можете уверенно сказать, что за пределы функции не должно выйти ни одно исключение, вы, определенно, должны объявить ее как noexcept.

Пожалуйста, обратите внимание на мои слова о том, что некоторые функции имеют естественную реализацию noexcept. Изменение реализации функции только для того, чтобы объявить ее как noexcept, — это хвост, виляющий собакой. Это телега перед лошадью. Это неумение увидеть лес за деревьями. Впрочем, довольно метафор. Если простая реализация функции может приводить к исключениям (например, путем вызова функции, которая может сгенерировать исключение), то попытка скрыть это исключение от вызывающего кода (например, перехватывая все исключения и заменяя их кодами состояния или специальными возвращаемыми значениями) усложнит не только реализацию вашей функции, но обычно и код в точке вызова. Например, вызывающая функция, как может оказаться, должна проверять код состояния или наличие специальных возвращаемых значений. Стоимость времени выполнения таких усложнений (например, дополнительных ветвлений, вызовов функций, которые будут влиять на кеши команд, и т.п.) легко может превысить ускорение, которое вы надеялись получить благодаря noexcept; кроме того, такой исходный код труднее понимать и поддерживать. Ничего хорошего из этого не получается.