Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 235
Текст из файла (страница 235)
То есть не обеспечи- вается основная гарантия Я Д.2). Если мы хотим доверять значениям и и зрасе и деструкторам элементов, следует предотвратить возможную утечку ресурсов; 1етр1аге<с1изз Т, с!азз А> иоЫ иес1аг<Т, А>сетегуепсу ех/Г() г(ез1гау е!етеп1з(1; Йгат Та1а1 /т/иге(у // очистка Д.3.5.3. Задержка выделения ресурса Подобно второму пункту Ц Д.3.5.2), третий (о задержке выделения ресурса до момента, когда он потребуется) неправильно применяет хорошую идею, так что издержки есть, а выгод нет.
Во многих случаях, особенно для контейнеров вроде иес1ог, лучший способ отложить выделение ресурса состоит в том, что программист откладывает создание объектов до момента, когда они понадобятся. Рассмотрим наивное использование иес1ог: иа!а1/(!п1 и) ( иес1аг<Х> и(п); //-. и[в]=Х(99); // газдаыив и объектов по улюл чапаю типа Х //реальная "инициализация'в/3/ Стандартный ивс1ог, заметим, спроектирован настолько аккуратно, что он минимизирует проблемы, вызываемые двухфазным созланием. Функция !и!1() примерно эквивалентна гез!ге(), и почти везде возможность и==О уже закрыта проверкамг в!ге()==0. Отрицательные эффекты, описанные для двухфазного создания, становятся более заметными при рассмотрении прикладных классов, захватывающих значительные ресурсы, типа сетевых соединений и файлов. Такие классы редко являются частью среды, которая направляет их использование и реализацию тем же образом, каким требования стандартной библиотеки руководят определением и использованием иесгог.
Проблемы также обостряются по мере усложнения соответствия между понятиями приложения и ресурсами, требуемыми для их реализации. Немногие классы отображаются на системные ресурсы так же непосредственно, как иес1ог. Идея «безопасного состояния» — в пршщипе хороша. Если мы не можем поместить объект в действительное состояние без риска сгенерировать исключение до завершения операции, у нас и в самом деле проблемы. Однако «безопасное состояние» должно быть естественной частью семантики класса, а не артефактом реализации, усложняющим инвариант класса.
1озт Д.4. Гарантии стандартных контейнеров Создание Х только для того, чтобы присвоить ему позже новое значение, расточительно — особенно если присваивание Х дорого. Поэтому может показаться привлекательным двухфазное создание Х. Например, тип Х может сам быть вес~ос, так что мы могли бы рассмотреть двухфазное создание пес~ог, чтобы оптимизировать создание пустых векторов. Однако создание заданных по умолчанию (пустых) векторов и так эффективно, поэтому усложнение реализации с частным случаем для пустого вектора представляется бесполезным. Вообще, «очистка» конструкторов элементов от сложной инициализации редко является наилучшим разрешением проблемы фиктивной инициализации. А вот пользователь вполне может создавать элементы только когда необходимо.
Например: вонЩглг эй ( весГог Х> в; //- // создание лустого вектора приз/э ЬасЦХ~99$~; //создание элеиента лри необходимости //- Подводя итог: двухфазное создание ведет к более сложным инвариантам и, как правило, к менее изящному, более подверженному ошибкам и более сложному для сопровождения коду. Следовательно всякий раз, когда это возможно, следует отдавать преимущество поддерживаемому языком «конструкторному подходу» по сравнению с «слсХ(1-подходом», То есть ресурсы должны выделяться в конструкторах, если только отложенное выделение ресурса не вынужденно унаследованной семантикой класса.
Д.4. Гарантии стандартных контейнеров Если сама библиотечная операция генерирует исключение, она может удостовериться, что объекты, с которыми она работает, оставлены в хорошо определенном состоянии. Библиотечные функции так и поступают. Например аэц, генерирующая ои1 о/ галде для пес1ог Я 16.3.3), не создает трудностей с обеспечением безопасности исключений в классе вес~ог, Автор ай1 без проблем убедится, что перед генерацией оес1ог находится в хорошо определенном состоянии.
Трудности для разработчи- . ков библиотеки, для пользователей библиотеки и для людей, пытающихся разобраться в коде, начинаются, когда исключение генерирует предоставленная пользователем функция. Контейнеры стандартной библиотеки предлагают основную гарантию 8 Д.2): соблюдаются основные инварианты библиотеки, и нет никаких утечек ресурсов, пока код пользователя ведет себя как подобает. То есть предоставленные пользователем операции не должны оставлять элементы контейнеров в недействительных состояниях или генерировать исключения в деструкторах.
Я имею в виду «операции», используемые реализацией стандартной библиотеки, типа конструкторов, присваиваний, деструкторов и операций с итераторами Я Д.4.4). Приложение Д. Безопасность исключений и стандартная библиотека 1038 Программисту довольно просто обеспечить, чтобы такие операции соответствовали ожиданиям библиотеки. Фактически даже наивно написанньэй код зачастую соответствует требованиям библиотеки. Следующие типы определенна удовлетворя!от требованиям стандартной библиотеки к типам контейнерных элементов: (1) встроенные типы — включая указатели; [2) типы без определенных пользователем операций; [3) классы с операциями, которые не генерируют исключении и не оставляют операнды в недействительных состояниях; (4] классы, деструкторы которых не генерируют исключений, и для которых просто проверить, что операции, используеьчые стандартной библиотекой [типа конструкторов, присваиваний, <, == и звар()/, пе оставляют операнды в недействительных состояниях.
В каждом случае мы должны также удостовериться, что нет никаких утечек ресурсов. Например: оо!дЯС!гс!е* рс, тг!апу!е' рй оес!от<Буаре*>с о2) ( оес!ос<Буаре*> о(! 0); о[3) =рс; о.!леег)(о.беу)п() + 4, р!); о2 егаяе(о2.6еу!и() + 3); //либо создает иес!ог, либо генерирует 6ад айос // исключения не генерируются //либо оставляет р1, лиоо ничего не делает с о // либо удаляет о2)3), либо ничего не делает с о2 о2= о; //-. //либо копирует о, либо ничего не делает с о2 Когда)() завершится, о должным образом уничтожится, а о2 останется в действительном состоянии.
Этот фрагмент не указывает, кто ответственен за удаление рс и р!. Если ответственнаЯ), она может либо перехватывать исключения и выполнять требуемое удаление, либо присваивать указатели локальным переменным типа аи!ар)г. Более интересный вопрос: когда библиотечные операции предлагают сильную гарантию, так что они либо успешно заканчиваются, либо не влияют на свои операнды? Например: оо!с!/(оес!ог<Х>й ох) ( охллеегг(ох.беу!л() + 4, Х(?)); // добаеление элел~ен~ а Вообще говоря, операции'Хи распределитель памяти оес4ог<Х> могут генерировать исключения. Что можно сказать об элементах ох, когдаЯ завершается из-за исключения? Основная гарантия заверяет, что нет утечек ресурсов, и что ох содержит набор действительных элементов. Но каких именно элементов? Изменился ли ох? Могло ли добавиться значение Хна умолчанию? Могли элемент быть удален, потому что это был единственный способ для !пзег!() восстановиться с соблюдением основной гарантии? Иногда недостаточно знать, что контейнер находится в хорошем состоянии; мы также хотим знать, что это за состояние.
После перехвата исключения обычно необходимо удостовериться, что элементы — точно те, какие и предполагались, в противном случае следует приступить к восстановлению после ошибок. Д.л. Гарантии стандартных контейнеров 1039 Д.4.1. Вставка и удаление элементов Вставка элемента в контейнер и удаление его оттуда — очевидные примеры опера- ций, которые могут оставить контейнер в непредсказуемом состоянии, если сгенери- ровано исключение. Причина в том, что вставка и удаление вызывают множество операций, которые вправе генерировать исключения: (1] В контейнер копируется новое значение.
(2] Должен быть уничтожен элемент, удаленный (вычеркнутый) из контейнера. (3] Иногда под новый элемент должна быть отведена память. (4] Иногда элементы пес1ог и Ыедие должны копироваться в новое место. (5] Ассоциативные контейнеры вызывают функции сравнения для элементов.
(б] Многие вставки и удаления включают операции с итераторами. Во всех подобных случаях могут генерироваться исключения. Если деструктор генерирует исключение, не дается никаких гарантий (9 Д.2), так как в подобном случае они обошлись бы непозволительно дорого. Однако библиоте- ка может защитить и защищает себя — и своих пользователей — от исключений, сге- нерированных другими предоставленными пользователем операциями. При обработке связной структуры данных наподобие 11в1 или тар, элементы мо- гут добавляться и удаляться без воздействия па другие элементы контейнера.
Иначе обстоит дело для контейнера, реализованного с помощью непрерывного размещения элементов, типа пес1ог или аедие. Там элементы иногда должны перемещаться на новые места. В дополнение к основной гарантии, стандартная библиотека предлагает сильную гарантию для нескольких операций, которые вставляют или удаляют элементы, По- скольку контейнеры, реализованные как связные структуры данных, ведут себя ина- че, чем контейнеры с непрерывным размещением элементов, стандарт обеспечивает слегка различные гарантии для разных видов контейнеров: [1] Гарантии для эес1ог (9 16.3) и Некие (9 17.23): — Если исключение сгенерировано в ризЬ Ьасп() илп ризй Ягоп1(), функция ни на что не влияет.
— Если исключение сгенерировано в 1пвег1(), но не копирующим конструктором и не оператором присваивания типа элемента, функция ни на что не влияет. — егаве() не генерирует исключений, кроме случаев возникновения исключения в копирующем конструкторе и в операторе присваивания типа элемента, — рор БасЯ и рор Ггоп1() не генерируют исключений. (2] Гарантии для Вэ1 (9 17.2.2): — Если исключение сгенерировано ризй Ьасй() или ризЬ ~гоп1(), функция ни на что не влияет.
— Если исключение сгенерировано 1пэег1(), функция ни ца что не влияет. — ег азе(), рор Баси(), рор 1гоп1(), вр11се(), и геьегве() не генерируют исключений, — Функции-члены 11в1: гетоэе(), гетопе (г]), ип1дие(), зог1() и тегае() не генерируют исключений, кроме случаев возникновения исключения в предикате или в функции сравнения. 1040 [3) Гарантии для ассоциативных контейнеров (э 17А): — Если исключение сгенерировано 1пзегт() при вставке отдельного элемента, функция ни на что не влияет.