Скотт Мейерс - Эффективное использование STL

template // Базовый шаблон для классов,

class Lock{// захватывающих и освобождающих мьютексы

public:// для контейнеров: многие технические

// детали опущены

Lock(const Containers container)

:c(container)

{

getMutexFor(с);// Захват мьютекса в конструкторе

}

~Lock () {

releaseMutexFor(c): // Освобождение мьютекса в деструкторе

}

private:

const Container& с;

Концепция управления жизненным циклом ресурсов (в данном случае — мьютексов) при помощи специализированных классов вроде Lock рассматривается в любом серьезном учебнике С++. Попробуйте начать с книги Страуструпа (Stroustrup) «The С++ Programming Language» [7], поскольку именно Страуструп популяризировал эту идиому, однако информацию также можно найти в совете 9 «More Effective С++». Каким бы источником вы ни воспользовались, помните, что приведенный выше класс Lockурезан до абсолютного минимума. Полноценная версия содержала бы многочисленные дополнения, не имеющие никакого отношения к STL. Впрочем, несмотря на минимализм, приведенная версия Lockвполне может использоваться в рассматриваемом примере:

vector v;

...

{// Создание нового блока

Lock > lock(v); // Получение мьютекса

vector::iterator first5(find(v.begin().v.end().5));

if (first5 != v.end()) {

*first5 - 0:

}

}// Закрытие блока с автоматическим

// освобождением мьютекса

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

Более того, решение, основанное на классе Lock,лучше защищено от исключений. С++ гарантирует уничтожение локальных объектов при возникновении исключения, поэтому Lockосвободит мьютекс, даже если исключение произойдет при использовании объекта Lock.При использовании парных вызовов getMutexFo r/ r eleaseMutexFor мьютекс не будет освобожден, если исключение происходит после вызова getMutexFor , но перед вызовом releaseMutexFor .

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

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

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

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

1.Выделенная память в дальнейшем должна быть освобождена оператором delete.Вызов newбез последующего deleteприводит к утечке ресурсов.

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

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

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

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

Кроме того, vector и string входят в семейство последовательных контейнеров STL, поэтому в вашем распоряжении оказывается весь арсенал алгоритмов STL, работающих с этими контейнерами. Впрочем, алгоритмы STL могут использоваться и с массивами, однако у массивов отсутствуют удобные функции begin, end, size и т. п., а также вложенные определения типов ( iterator , reverse_iterator , value_typeи т. д.), а указатели char*вряд ли могут сравниться со специализированными функциями контейнера string. Чем больше работаешь с STL, тем меньше энтузиазма вызывают встроенные массивы.