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

Функции 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.