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

Когда в std::vectorдобавляется новый элемент, может оказаться, что в std::vectorдля него не хватает места, т.e. что размер std::vectorравен его емкости. Когда такое случается, std::vectorвыделяет новый, больший по размеру блок памяти для хранения своих элементов и переносит элементы из старого блока в новый. В С++98 перенос осуществляется с помощью копирования каждого элемента из старой памяти в новую с последующим удалением объекта в старой памяти. Этот подход позволяет push_backобеспечить строгую гарантию безопасности исключений: если исключение будет сгенерировано в процессе копирования элементов, то состояние std::vectorостанется неизменным, поскольку ни один элемент в старом блоке памяти не будет удален, пока все элементы не будут успешно скопированы в новое место в памяти.

В С++11 естественной оптимизацией была бы замена копирования элементов std::vectorперемещениями. К сожалению, это ведет к риску нарушения строгой гарантии push_back. Если nэлементов перемещены из старого блока памяти в новый и при перемещении n+1-го элемента генерируется исключение, операция push_backне может быть завершена. Но при этом исходный std::vectorнаходится в измененном состоянии: nего элементов уже перемещены. Восстановление их исходных состояний может оказаться невозможным, поскольку попытка перемещения каждого объекта обратно в исходное местоположение в памяти также может привести к генерации исключения.

Это серьезная проблема, поскольку поведение старого кода может зависеть от строгой гарантии безопасности функции push_back. Следовательно, реализации С++11 не могут молча заменить операции копирования внутри push_backоперациями перемещения, если только точно не известно, что операции перемещения не генерируют исключений. В таком случае замена копирований перемещениями должна быть безопасной, и единственным побочным эффектом этой замены будет повышение быстродействия.

Функция std::vector::push_backиспользует преимущество этой стратегии (“перемести, если можешь, но копируй, если должен”), и это не единственная функция стандартной библиотеки, поступающая таким образом. Другие функции, обеспечивающие строгую гарантию безопасности исключений в С++98 (например, std::vector::reserve, std::deque::insertи др.), ведут себя точно так же. Все эти функции заменяют вызовы копирующих операций в С++98 вызовами перемещающих операций в С++11, только если известно, что перемещающие операции не генерируют исключений. Но как функция может узнать, генерирует ли исключения операция перемещения? Ответ очевиден: она должна проверить, объявлена ли операция как noexcept [7] Проверка обычно выполняется окольным путем. Функции наподобие std::vector::push_back вызывают шаблон std::move_if_noexcept , вариацию шаблона std::move , который условно выполняет приведение к rvalue (см. раздел 5.1), в зависимости от того, объявлен ли перемещающий конструктор как noexcept . В свою очередь, std::move_if_noexcept консультируется с std::is_nothrow_move_constructible , а значение этого свойства типа (см. раздел 3.3) устанавливается компиляторами в зависимости от того, объявлен ли перемещающий конструктор как noexcept (или throw() ). .

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