распределителя памяти (такое изменение не влияет на правила недействительности итераторов/указателей/ссылок).

class Wiclget{...};

tempiate<typename Т> В совете 10 объясняется, почему

SpecialAnocator{...}; необходимо использовать шаблон

typedef vectbr<Widget.SpecialAllocator<Widget WidgetContainer: typedef WidgetContainer::-iterator WCIterator;

WidgetContainer vw; Работает

Widget bestWidget:

WCIterator i=find(vw.begin().vw.end().bestWidget): Работает

Даже если вас не интересуют аспекты typedef, связанные с инкапсуляцией, вы наверняка оцените экономию времени. Предположим, у вас имеется объект типа

map<string.

vector<Widget>::iterator.

CIStringCompare> ClStringCompare - сравнение строк

без учета регистра: см. совет 19

и вы хотите перебрать элементы множества при помощи const i terator. Захочется ли вам вводить строку

map<string.vector<Widget>::iterator,CIStringCompare>::const iterator

больше одного раза? После непродолжительной работы в STL вы поймете, что typedef - ваш друг.

Typedef всего лишь определяет синоним для другого типа, поэтому инкапсуляция производится исключительно на лексическом уровне. Она не помешает клиенту сделать то, что он мог сделать ранее (и не позволит сделать то, что было ранее недоступно). Если вы захотите ограничить зависимость клиента от выбранного типа контейнера, вам понадобятся более серьезные средства - классы.

Чтобы ограничить объем кода, требующего модификации при замене типа контейнера, скройте контейнер в классе и ограничьте объем информации, доступной через интерфейс класса. Например, если вам потребуется создать список клиентов, не используйте класс list напрямую, определите класс CustomerList и инкапсулируйте 1 i st в его закрытой части:

class CustomerList { private:

typedef 1ist<Customer> CustomerContainer; typedef CustomerContainer::iterator CClterator:

CustomerContainer customers:

public: Объем информации, доступной

через этот интерфейс, ограничивается

На первый взгляд происходящее выглядит глупо. Ведь список клиентов - это список, не правда ли? Вполне возможно. Но в будущем может оказаться, что возможность вставки-удаления в середине списка используется не так часто, как

предполагалось вначале, зато нужно быстро выделить 20% клиентов с максимальным объемом сделок - эта задача просто создана для алгоритма nthel ement (совет 31). Однако nthel ement требует итератора произвольного доступа и не будет работать с контейнером 1 ist. В этой ситуации список лучше реализовать на базе vector или deque.

Рассматривая подобные изменения, необходимо проанализировать все функции класса CustomerList, а также всех друзей (friend) и посмотреть, как на них отразится это изменение (в отношении быстродействия, недействительности итераторов/указателей/ссылок и т. д.), но при грамотной инкапсуляции деталей реализации CustomerLi st это изменение практически не повлияет на клиентов CustomerLiSt.

Совет 3. Реализуйте быстрое и корректное копирование объектов в контейнерах

в контейнерах хранятся объекты, но не те, которые вы им передаете. Более того, при ползении объекта из контейнера вам предоставляется не тот объект, который находился в контейнере. При включении объекта (вызовом i nsert, push back и т. д.) в контейнер заносится копия указанного объекта. При ползении объекта из контейнера (например, вызовом front или back) вы также получаете копию. Копирование на входе, копирование на выходе - таковы правила STL.

Но и после того, как объект окажется в контейнере, он может участвовать в операциях копирования. В результате вставки или удаления элементов в vector, string и deque существующие элементы контейнера обычно перемещаются (копируются) в памяти (советы 5 и 14). Алгоритмы сортировки (совет 31), next permutation и previous permutation; remove, unique и их родичи (совет 32); rotate и reverse - все эти операции приводят к копированию объектов. Да, копирование объектов действительно занимает очень важное место в STL.

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

class Widget{ public;

WidgetCconst WidgetS); Копирующий конструктор

Widgets operator=(const WidgetS): Копирующий оператор присваивания

}:

Как обычно, если вы не объявите эти функции самостоятельно, компилятор сделает это за вас. Встроенные типы (int, указатели и т. д.) копируются простым копированием их двоичного представления. Копирующие конструкторы и операторы присваивания описаны в любом учебнике по C-i-i-. В частности, эти функции рассмотрены в советах 11 и 27 книги Effective С++ .

Теперь вам должен быть ясен смысл этого совета. Если контейнер содержит объекты, копирование которых сопряжено с большими затратами, простейшее занесение объектов в контейнер может заметно повлиять на скорость работы программы. Чем больше объектов перемещается в контейнере, тем больше памяти и тактов процессора расходуется на копирование. Более того, у некоторых объектов само понятие копирование имеет нетрадиционный смысл, и при занесении таких объектов в контейнер неизменно возникают проблемы (пример приведен в совете 8).

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

vector<Widget> vw;

class SpecialWidget: SpecialWidget наследует от класса

public Widget{...}; Widget (см. ранее)

SpecialWidget sw: sw копируется в vw как объект базового класса

vw.push back(sw): Специализация объекта теряется (отсекается)

в процессе копирования

Проблема отсечения предполагает, что вставка объекта производного класса в контейнер объектов базового класса обычно приводит к ошибке. А если вы хотите, чтобы полученный объект обладал поведением объекта производного класса (например, вызывал виртуальные функции объектов производного класса), вставка всегда приводит к ошибке. За дополнительной информацией обращайтесь к Effective С++ , совет 22. Другой пример проявления этой проблемы в STL описан в совете 38.

Сушествует простое решение, обеспечивающее эффективное, корректное и свободное от проблемы отсечения копирование - вместо объектов в контейнере хранятся указатели. Иначе говоря, вместо контейнера для хранения Widget создается контейнер для Widget*. Указатели быстро копируются, результат точно совпадает с ожидаемым (поскольку копируется базовое двоичное представление), а при копировании указателя ничего не отсекается. К сожалению, у контейнеров указателей имеются свои проблемы, обусловленные спецификой STL. Они рассматриваются в советах 7 и 33. Пытаясь справиться с этими проблемами и при этом не нажить хлопот с эффективностью, корректностью и отсечением, вы, вероятно, обнаружите симпатичную альтернативу - умные указатели. За дополнительной информацией обращайтесь к совету 7.

Если вам показалось, что STL злоупотребляет копированием, не торопитесь с выводами. Да, копирование в STL выполняется довольно часто, но в целом библиотека спроектирована с таким расчетом, чтобы избежать лишнего копирования. Более того, она избегает лишнего создания объектов. Сравните с поведением классического массива - единственного встроенного контейнера С и С++:

Widget wEmaxNuinWidgets]: Создать массив объектов Widget

Объекты инициализируются конструктором по умолчанию