Более того, решение, основанное на классе

, лучше защищено от исключений. C++ гарантирует уничтожение локальных объектов при возникновении исключения, поэтому освободит мьютекс, даже если исключение произойдет при использовании объекта . При использовании парных вызовов мьютекс не будет освобожден, если исключение происходит после вызова , но перед вызовом .

Исключения и управление ресурсами важны, но данный совет посвящен другой теме — потоковой безопасности в STL. Как говорилось выше, вы можете надеятьсяна то, что реализация библиотеки обеспечивает параллельное чтение из одного контейнера и одновременную запись в разные контейнеры. Не надейтесь, что библиотека избавит вас от ручной синхронизации и не рассчитывайте на поддержку многопоточности.

Все контейнеры STL по-своему полезны, однако большинство программистов C++ работает с

и string чаще, чем с их собратьями, и это вполне понятно. Ведь контейнеры и разрабатывались как замена массивов, а массивы настолько полезны и удобны, что встречаются во всех коммерческих языках программирования от COBOL до Java.

В этой главе контейнеры

и рассматриваются с нескольких точек зрения. Сначала мы разберемся, чем они превосходят классические массивы STL, затем рассмотрим пути повышения быстродействия и , познакомимся с различными вариантами реализации , изучим способы передачи и функциям API, принимающим данные в формате C. Далее будет показано, как избежать лишних операций выделения памяти. Глава завершается анализом поучительной аномалии, .

Принимая решение о динамическом выделении памяти оператором

, вы берете на себя ряд обязательств.

1. Выделенная память в дальнейшем должна быть освобождена оператором

. Вызов без последующего приводит к утечке ресурсов.

2. Освобождение должно выполняться соответствующей формой оператора

. Одиночный объект освобождается простым вызовом , а для массивов требуется форма . Ошибка в выборе формы приводит к непредсказуемым последствиям. На одних платформах программа «зависает» во время выполнения, а на других она продолжает работать с ошибками, приводящими к утечке ресурсов и порче содержимого памяти.

3. Оператор

для освобождаемого объекта должен вызываться ровно один раз. Повторное освобождение памяти также приводит к непредсказуемым последствиям.

Итак, динамическое выделение памяти сопряжено с немалой ответственностью, и я не понимаю, зачем брать на себя лишние обязательства. При использовании

и необходимость в динамическом выделении памяти возникает значительно реже.

Каждый раз, когда вы готовы прибегнуть к динамическому выделению памяти под массив (то есть собираетесь включить в программу строку вида «

»), подумайте, нельзя ли вместо этого воспользоваться или . Как правило, используется в том случае, если является символьным типом, а — во всех остальных случаях. Впрочем, позднее мы рассмотрим ситуацию, когда выбор выгладит вполне разумно. Контейнеры и избавляют программиста от хлопот, о которых говорилось выше, поскольку они самостоятельно управляют своей памятью. Занимаемая ими память расширяется по мере добавления новых элементов, а при уничтожении или деструктор автоматически уничтожает элементы контейнера и освобождает память, в которой они находятся.

Кроме того,

и входят в семейство последовательных контейнеров STL, поэтому в вашем распоряжении оказывается весь арсенал алгоритмов STL, работающих с этими контейнерами. Впрочем, алгоритмы STL могут использоваться и с массивами, однако у массивов отсутствуют удобные функции , , и т. п., а также вложенные определения типов ( и т. д.), а указатели вряд ли могут сравниться со специализированными функциями контейнера . Чем больше работаешь с STL, тем меньше энтузиазма вызывают встроенные массивы.

Если вас беспокоит судьба унаследованного кода, работающего с массивами, не волнуйтесь и смело используйте

и . В совете 16 показано, как легко организовать передачу содержимого и функциям C, работающим с массивами, поэтому интеграция с унаследованным кодом обычно обходится без затруднений.

Честно говоря, мне приходит в голову лишь одна возможная проблема при замене динамических массивов контейнерами

, причем она относится только к . Многие реализации основаны на подсчете ссылок (совет 15), что позволяет избавиться от лишних выделений памяти и копирования символов, а также во многих случаях ускоряет работу контейнера. Оптимизация на основе подсчета ссылок была сочтена настолько важной, что Комитет по стандартизации C++ специально разрешил ее использование.

Впрочем, оптимизация нередко оборачивается «пессимизацией». При использовании

с подсчетом ссылок в многопоточной среде время, сэкономленное на выделении памяти и копировании, может оказаться ничтожно малым по сравнению со временем, затраченным на синхронизацию доступа (за подробностями обращайтесь к статье Саттера «Optimizations That Aren't (In a Multithreaded World)» [20]). Таким образом, при использовании с подсчетом ссылок в многопоточной среде желательно следить за проблемами быстродействия, обусловленными поддержкой потоковой безопасности.