3a информацией о типе pointer, a также о преобразовании типа и умножении при вызове а! 1 ocate обращайтесь к совету 10. Пример использования SharedMemoryAl 1 ocator:

Вспомогательное определение типа typedef

vector<doublе.SharedMemoryAllocator<double> > SharedDoubleVec;

{ Начало блока

SharedDoubleVec v: Создать вектор, элементы которого

находятся в общей памяти

} Конец блока

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

Итак, в результате хронометража, профилирования и всевозможных экспериментов вы пришли к выводу, что стандартный распределитель памяти STL (то есть а! 1 ocator<T>) работает слишком медленно, напрасно расходует или фрагментиру-ет память, и вы лучше справитесь с этой задачей. А может быть, а! 1 ocator<T> обеспечивает безопасность в многопоточной модели, но вы планируете использовать только однопоточную модель и не желаете расходовать ресурсы на синхронизацию, которая вам не нужна. Или вы знаете, что объекты некоторых контейнеров обычно используются вместе, и хотите расположить их рядом друг с другом в специальной куче, чтобы по возможности локализовать ссылки. Или вы хотите выделить блок обшей памяти и разместить в нем свои контейнеры, чтобы они могли использоваться другими процессами. Превосходно! В каждом из этих сценариев уместно воспользоваться нестандартным распределителем памяти.

Предположим, у вас имеются специальные функции для управления блоком общей памяти, написанные по образцу mal 1 ос и free:

void* manocShared(size t bytesNeeded): void freeShared(void *ptr):

Требуется, чтобы память для содержимого контейнеров STL выделялась в общем блоке. Никаких проблем:

tempiate<typename Т>

class SharedMemoryAllocator{

public:

pointer allocate(size type numObjects, const void *localityHint=0) {

return static cast<pointer>(mal1ocShared(nunObjects *sizeof(T))):

void deallocate(pointer ptrToMemory, size type numObjects) {

freeShared(ptrToMemory);

Обратите особое внимание на формулировку комментария рядом с определением V. Вектор V использует SharedMemoryAllocator, поэтому память для хранения элементов v будет выделяться из общей памяти, однако сам вектор v (вместе со всеми переменными класса) почти наверняка не будет находиться в общей памяти. Вектор V - обычный стековый объект, поэтому он будет находиться в памяти, в которой исполнительная система хранит все обычные стековые объекты. Такая память почти никогда не является общей. Чтобы разместить в общей памяти как содержимое v, так и сам объект v, следует поступить примерно так:

void *pVectorMemory = Выделить блок общей памяти,

manocShared(sizeof(SharedOoubleVec)): обьем которой достаточен

для хранения объекта

SharedDoubleVec

SharedOoubleVec *pv = Использовать new с явным

new (pVectorMemory) SharedDoubleVec; размещением для создания

объекта SharedDoubleVec;

см. далее.

Использование объекта (через pv)

pv->-SharedDoubleVec(); Уничтожить объект в общей памяти

freeShared(pVectorMemory); Освободить исходный блок

общей памяти

Надеюсь, смысл происходящего достаточно ясен из комментариев. В общих чертах происходит следующее; мы выделяем блок общей памяти и конструируем в ней vector, использующий общую память для своих внутренних операций. После завершения работы с вектором мы вызываем его деструктор и освобождаем память, занимаемую вектором. Код не так уж сложен, но все-таки он не сводится к простому объявлению локальной переменной, как прежде. Если у вас нет веских причин для того, чтобы в общей памяти находился сам контейнер (а не его элементы), я рекомендую избегать четырехшагового процесса выделение/конструирование/уничтожение/освобождение .

Несомненно, вы заметили: в приведенном фрагменте проигнорирована возможность того, что та! 1 ocShared может вернуть nul 1. Разумеется, в окончательной версии следовало бы учесть такую возможность. Кроме того, конструирование vector в общей памяти производится конструкцией new с явным размещением , описанной в любом учебнике по С++.

Рассмотрим другой пример использования распределителей памяти. Предположим, у нас имеются две кучи, представленные классами Heapl и Неар2. Каждый из этих классов содержит статические функции для вьщеления и освобождения памяти:

class Heapl { public:

static void* alloc(size t numBytes. const void* memoryBlockloBeNear); static void dealloc(void *ptr):

class Heap2 {...}; Тот же интерфейс alloc/dealloc

Далее предположим, что вы хотите разместить содержимое контейнеров STL в заданных кучах. Сначала следует написать распределитель, способный использовать классы Heapl и Неар2 при управлении памятью:

Затем Speci al HeapAl 1 ocator группирует элементы контейнеров:

vector<int.SpecificHeapAllocator<int,Heapl> > v: Разместить элементы set<int.SpecificHeapAllocator<int.Heapl> > s: v и s в Heapl

11st<Widget.

SpecificHeapAllocator<Widget,Heap2> > L: Разместить элементы map<int,string.less<int>. L и m в Heap2

Speci ficHeapAl1ocator<pai r<const i nt,stri ng>, Heap2> > m;

В приведенном примере очень важно, чтобы Heapl и Неар2 были типами, а не объектами. В STL предусмотрен синтаксис инициализации разных контейнеров STL разными объектами распределителей одного типа, но я не буду его приводить. Дело в том, что если бы Heapl и Неар2 были бы объектами вместо типов, это привело бы к нарушению ограничения эквивалентности, подробно описанного в совете 10.

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

Совет 12. Разумно оценивайте потоковую безопасность контейнеров STL

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

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

tempiate<typename Т. typename Heap

SpecificHeapAllocator{ public:

pointer allocate(size type numObjects.const void *localityHint=0) {

return static cast<pointer> (Heap::alloc(numObjects*sizeof(T). localityHint)):

void deallocateCpointer ptrToMemory,size type numObjects) {

Hea p::dea11 ОС(pt rloMemory):