С. Мейерс - Эффективный и современный C++ (1114942), страница 23

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 23)

В С++98 перенососуществляется с помощью копирования каждого элемента из старой памяти в новуюс последующим удалением объекта в старой памяти. Этот подход позволяет push_backобеспечить строгую гарантию безопасности исключений: если исключение будет сгене­рировано в процессе копирования элементов, то состояние s t d : : vector останется не­изменным, поскольку ни один элемент в старом блоке памяти не будет удален, пока всеэлементы не будут успешно скопированы в новое место в памяти.В С++ 1 1 естественной оптимизацией была бы замена копирования элементовstd : : vector перемещениями. К сожалению, это ведет к риску нарушения строгой гаран­тии push back. Если n элементов перемещены из старого блока памяти в новый и приперемещении n+ 1 -го элемента генерируется исключение, операция push back не может__1 00Глава 3.

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

В таком случае замена копирований перемещениями должна быть безопасной,и единственным побочным эффектом этой замены будет повышение быстродействия.Функция s t d : : vector : : push_back использует преимущество этой стратегии ("пере­мести, если можешь, но копируй, если должен"), и это не единственная функция стан­дартной библиотеки, поступающая таким образом.

Другие функции, обеспечивающиестрогую гарантию безопасности исключений в С++98 (например, std : : vector : : reserve,s t d : : deque : : insert и др.), ведут себя точно так же. Все эти функции заменяют вызо­вы копирующих операций в С++98 вызовами перемещающих операций в С++ 1 1 , толькоесли известно, что перемещающие операции не генерируют исключений. Но как функцияможет узнать, генерирует ли исключения операция перемещения? Ответ очевиден: онадолжна проверить, объявлена ли операция как noexcept•.Функции swap являются еще одним случаем, когда модификатор noexcept особенножелателен.

Функция swap является ключевым компонентом множества реализаций ал­горитмов STL и обычно использует операторы копирующего присваивания. Ее широкоеприменение делает оптимизацию на основе noexcept особенно важной. Интересно, что то,является ли функция swap в стандартной библиотеке noexcept, иногда зависит от того, яв­ляются ли таковыми функции swap, определенные пользователями. Например, объявленияswap в стандартной библиотеке для массивов и std : : pa i r имеют следующий вид:template <class Т, s i ze t N>void swap ( T ( &а ) [N] ,/ / См . нижеТ ( &Ь) [ N ] ) noexcept (noexoept (swap (*a, *Ь) ) ) ;template <class T l , c lass Т2>struct pair {void swap (pair& р ) noexcept (noexcept (swap (first, p . first) ) &&noexcept (swap (second , p .

second) ) ) ;};' Проверка обычно выполняется окольным путем. Функции наподобие s t d : : vector : : push_back вызывают шаблон std: : move_i f_noexcept, вариацию шаблона std : : move, который услов­но выполняет приведение к rvalue (см.

раздел 5.1), в зависимости от того, объявлен ли переме­щающий конструктор как noexcept. В свою очередь, s t d : : move_i f_noexcept консультируетсяс std: : is _nothrow_move constructiЬle, а значение этого свойства типа (см. раздел 3.3) устанав­ливается компиляторами в зависимости от того, объявлен ли перемещающий конструктор какnoexcept (или throw ( ) ) ._3 .8. Если функции не генерируют исключений, объявляйте их как noexcept101Эти функции являются условно noexcept: являются ли они nоехсерt-функциями, за­висит от того, являются ли таковыми инструкции в конструкции noexcept.

Для двух за­данных массивов Widget, например, их обмен с помощью функции swap будет считатьсяnoexcept только в том случае, если таковыми будут операции обмена отдельных элемен­тов; т.е. если функция swap для Widget объявлена как noexcept. Таким образом, авторфункции swap класса Widget определяет, будет ли операция обмена массивов Widget рас­сматриваться как noexcept.

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

Увы, должен умерить ваш энтузиазм. Оптимизация важна, но коррект­ность важнее. В начале этого раздела я отмечал, что noexcept является частью интерфей­са функции, так что вы должны объявлять функцию как noexcept, только если вы готовыобеспечивать это свойство в течение длительного срока.

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

Нейтральные по отношению к исключениям функции никогда не являютсяnoexcept, поскольку их могут покидать такие "проходящие" исключения. Поэтому боль­шинство функций совершенно корректно не используют спецификацию noexcept.Некоторые функции, однако, имеют естественные реализации, которые не генериру­ют никаких исключений, а еще некоторое их количество (в основном операции пере­мещения и обмена), будучи noexcept, могут дать столь значительный выигрыш, что ихстоит реализовывать как noexcept, насколько это возможно7• Когда вы можете уверенно7 В спецификациях интерфейса для операций перемещения в контейнерах стандартной библиотекиотсутствует.

Однако разработчикам разрешено усиливать спецификации интерфейс011функций стандартной библиотеки, и на практике как минимум для некоторых контейнеров опе­рации перемещения объявляются как noexcept. Эта практика является примером следования со­вету из данного раздела. Обнаружив, что можно написать операции перемещения так, что исклю­чения гарантированно не будут генерироваться, разработчики часто объявляют такие операциикак noexcept, несмотря на то что стандарт языка от них этого не требует.noexcept102Глава 3 . Переход к современному С++сказать, что за пределы функции не должно выйти ни одно исключение, вы, определенно,должны объявить ее как noexcept.Пожалуйста, обратите внимание на мои слова о том, что некоторые функции имеютестественную реализацию noexcept .

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

Стоимость времени выполнения таких усложнений (например, допол­нительных ветвлений, вызовов функций, которые будут влиять на кеши команд, и т.п.)легко может превысить ускорение, которое вы надеялись получить благодаря noexcept;кроме того, такой исходный код труднее понимать и поддерживать. Ничего хорошего изэтого не получается.Для некоторых функций отсутствие исключений настолько важно, что они явля­ются noexcept по умолчанию. В С++98 считается плохим стилем разрешать генериро­вать исключения функциям освобождения памяти (т.е.

операторам ope rator d e l e t eи operator delete [ ] ) и деструкторам, а в C++ l l это правило стиля стало правиломязыка. По умолчанию все функции освобождения памяти и все деструкторы - какпользовательские, так и генерируемые компиляторами - неявно являются noexcep t .Поэтому необходимости явно объявлять их таковыми нет. (Это ничему не повредит,это просто необычно.) Единственная ситуация, когда деструктор не является неявнообъявленным как noexcept, - это когда член-данные класса (включая унаследованныечлены и содержащиеся внутри других членов-данных) имеет тип, который явно указы­вает, что его деструктор может генерировать исключения (например, объявленный какnoexcept ( fa l s e ) ).

Характеристики

Список файлов книги