Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 235
Текст из файла (страница 235)
Однако при неправильном упорядочении кола возникает больше проблем с достижением безопасности исключений, чем из-за отсутствия особого кода обработки ошибок. Основное правило упорядочения кода — не уничтожать старую информацию до того, как будут полностью созданы новые данные, присваивание которых не подвержено риску возникновения исключений. Исключения создают почву для неожиданностей по части изменений потока управления (то есть последовательности выполнения операторов программы). В простых локальных фрагментах кода, в которых доминирует линейная последовательность вызовов орегагог= (), юа/е атютяи() и риюЬ Ьасlс(), возможностей для подобного рода сюрпризов мало.
Однако в больших функциях, содержащих множество циклов и условных операторов, прогноз сделать труднее. Добавление югу-блоков лишь увеличивает сложность управления, и может служить источником недоразумений и ошибок (514.4). Поэтому подход с упорядочением кода и следованием методике «выделение ресурса есть инициализация» имеет и здесь преимущество; упрощается контроль за потоком исполнения кода программы. Простой, элегантный код всегда легче понять и отладить. Отметим, что рассмотренная нами реализация чес(ог приведена лишь с целью иллюстрации трудностей, которые могут породить исключения, а также методов их преодоления. Стандарт не требует от реализаций библиотеки следовать этим рекомендациям. Настоящие гарантии стандарта рассмотрены ниже в 5Е.4. Е.З.
Технологии реализации безопасности при исключениях 1093 Е.3.5. Конструкторы и инварианты С точки зрения безопасности исключений другие операции для типа яес!ог или эквивалентны уже рассмотренным (поскольку приобретают и освобождают ресурсы схожим образом), или тривиальны (не требуют соблюдения действительных состояний участвующих в них объектов). Эти операции для большинства классов составляют большую часть кода, а легкость их написания критически зависит от среды, устанавливаемой конструктором для их исполнения. Говоря иначе, все зависит от качества выбора инварианта класса (924.3.7.1).
Изучение тривиальных функций класса поможет нам понять, что делает инвариант класса хорошим, и как нужно писать конструкторы, чтобы они устанавливали хорошие инварианты. Такие операции, как индексирование векторов (916.3.3), писать просто, поскольку они могут положиться на инвариант, устанавливаемый конструкторами и поддерживаемый всеми функциями, которые захватывают или освобождают ресурсы.
В частности, операция индексирования может положиться на то, что поле я ссылается на массив элементов: гетр1аяекс1аяя Т, с(аяя А> Та гесяог<Т,А>::орегаяог() (яме (уре1) ( гтигл я(11; Крайне важно, чтобы конструкторы, захватывая ресурсы, устанавливали простой инвариант. Чтобы понять, почему это так важно, рассмотрим альтернативное определение яес!ог Ьаяе: гетр1аяе<с!ат Т, с(ат А = авоса(огкT» с1ат гас!ос Ьаяс ( риЫ!с: А аПос; Т* яг Т* яраса; Т* 1аин гесгог Ьаяе(соня! Аа а, яуреиате А::я!яе гуре и) : аПос(а), г(0), грасс(0), 1ат(0) ( г = аПос.аПоса!е(и) ярасе = 1ам = |н.и ! -яесяог Ьаяе() ((Т(г) аИос.деайосаяе(г,1аяя-г); ) ): Здесь я создаю яес!ог Ьаяе в две стадии: сначала я создаю безопасное (надежное) состояние с я, яраса и Ьяят равными нулю, и только после этого пробую выделять память.
Все это сделано из необоснованного опасения, что во время выделения памяти под элементы произойдет исключение, и конструктор оставит после себя частично созданный объект. Однако это опасение необосновано, так как невозможно оставить после себя частично созданный обьект и позднее обратиться к нему — правила для статических и автоматических объектов, объектов-членов класса и элементов контейнеров Приложение Е Исключения и безопасность стандартной библиотеки 1094 стандартной библиотеки предотвращают такую возможность. Это было возможно для «достандартных» вариантов библиотеки, которые использовали операцию «размещающее печ<ь (5!0.4.11) для создания объектов в контейнерах, разработанных без учета безопасности исключений.
Привычки, однако, изживаются с трудом. Отметим, что предпринятая нами попытка написать код «побезопаснееьч лишь усложняет инвариант для класса: уже не гарантируется, что г указывает на выделенную память. Теперь поле о может быть равно О, а это немедленно вызывает проблемы, так как в стандартной библиотеке для аллокаторов не гарантируется безопасное освобождение памяти по нулевому указателю (519.4.1). В этом отношении аллокаторы отличаются от операции <(е1е<е (96.2.6). В итоге, пришлось предусмотреть в деструкторе соответствующую проверку.
Кроме того, каждый элемент сначала инициализируется нулем, после чего ему присваивается значение. Стоимость этой лишней работы может оказаться существенной для типов элементов, у которых операция присваивания нетривиальна (вроде з<Г!пя или!1з<). Рассмотренный двухступенчатый конструктор не так уж необычен. Иногда этот стиль делают явным, оставляя конструктору лишь простую и безопасную инициализацию, обеспечивающую корректное состояние обьекта для его потенциального уничтожения. Реальное же создание объекта оставляется функции <и«(), которую пользователь должен вызвать явно. Например: У архаичный стиль <е<пр1а<е<с!ат Т> с1авз вес<ос Ьазе ( риЬ1<с: Т* г; Т* зрасе< Т* 1аз« гес<ог Ьазе(): г(0), юрасе(0), <аз<(0) () -гес<ог Ьазе() (<гее(г) < ] Ьоо! <п1<(з(хе < п) Увозвращает оие в случаеуспешной инициализации ( (< ( г = ( Т* ) таИос (з(хео! ( Т) * и ) ) ( ип<п(<(а<<хе<1 11Н(г, г«п, Т() ); зрасе = <аз< = г«п < ге<ига <гие< ) ге<ига Та<ее < ) )< Предполагается, что ценность данного стиля состоит в том.
что: 1. Конструктор не генерирует исключений, а успешность отработки функции ии<() можно проконтролировать обычными (то есть без исключений) средствами. 2. Существует тривиальное действительное состояние. При возникновении проблем операция может придать это состояние объекту. 3. Выделение ресурсов откладывается до момента, когда на самом деле возникает нужда в полностью инициализированном объекте. 1095 Е.З. Технологии реализации безопасности при исключениях Все эти пункты изучаются в последующих разделах, где показывается, почему зта двухступенчатая методика создания объектов не приносит ожидаемых выгод.
Более того, она может стать источником проблем. ЕЗ.5.1. Применение функции )пй() Первый пункт (использование функции йиг() вместо полноценного конструктора) — это ложная идея. Полноценные конструкторы и обработка исключений— намного более общий и систематический способ работы с ресурсами и ошибками инициализации (914.1, 914.4).
Применение функции !и!г () — это пережиток эпохи «достандартного» С++ в отсутствие механизма исключений. Тщательно составленный код обоих стилей более-менее эквивалентен друг другу. Рассмотрим следующие примеры: !пг )7 (!пг и ) ( гестог<Х> гэ // ... эу(г.!пй(п) ) ( // используем э вектор иэ п элементов е!эе ( //улаживаем проблему ) ) !пг (2 (йм и ) тгу ( гесгог<Х> г(п); // ... // используем э вектор иэ п элементов ) сагой (... ) ( /улаживаем проблему При всем при этом, использование отдельной функции !пй() — это возможность: 1. Забыть вызвать !л!т() (э!0.2.3). 2.
Забыть проверить успешность отработки !л!т() . 3. Вызвать йиг() более одного раза. 4. Забыть, что элй() может сгенерировать исключение. 5. Использовать объект до вызова !лй() . В хорошей реализации С++ функция!2 () чуть быстрее функции Л ( ), поскольку она избегает в общем случае проверки. Приложение Е. Исключения и безопасность стандартной библиотеки 1096 Е.3.5.2. Полагаемся на действительное состояние по умолчанию Второй пункт (простое действительное состояние по умолчанию) в общем случае правилен, но для чес(от он ведет к ненужным расходам: теперь гесгог Ьазе может иметы-=О, так что в реализации типа чес(от нужно всюду защищаться от этого.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
