Эффективное использование STL

Мейерс Скотт

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

return static_cast<pointer>(mal1ocShared(numObjects *szeof(T)));

 }

 void deallocate(pointer ptrToMemory, size_type numObjects) {

freeShared(ptrToMemory);

 }

 …

};

За информацией о типе pointer, а также о преобразовании типа и умножении при вызове allocate обращайтесь к совету 10. Пример использования

SharedMemoryAllocator

:

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

typedef

vector<double, SharedMemoryAllocator<double> > SharedDoubleVec;

…

{ //

Начало блока

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

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

} // Конец блока

Обратите особое внимание на формулировку комментария рядом с определением

v

. Вектор

v

использует

SharedMemoryAllocator

, потому память для хранения элементов

v

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

v

(вместе со всеми переменными класса) почти наверняка не будет находиться в общей памяти. Вектор

v

— обычный стековый объект, поэтому он будет находиться в памяти, в которой исполнительная система хранит все обычные стековые объекты. Такая память почти никогда не является общей. Чтобы разместить в общей памяти как содержимое

v

, так и сам объект

v

, следует поступить примерно так:

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

 mallocShared(sizeof(SharedOoubleVec)); // обьем которой достаточен

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

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

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

// объекта SharedDoubleVec:

// см. далее.

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

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

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

// общей памяти

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

vector

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

Несомненно, вы заметили: в приведенном фрагменте проигнорирована возможность того, что

mallocShared

может вернуть

null

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

new

с явным размещением», описанной в любом учебнике по C++.

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

Heap1

и

Неар2

. Каждый из этих классов содержит статические функции для выделения и освобождения памяти:

class Heap1 {

public:

 …

 static void* alloc(size t numBytes, const void* memoryBlockToBeNear);

 static void dealloc(void *ptr);

 …

};

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

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

Heap1

и

Heap2

при управлении памятью:

template<typename T, typename Heap>

SpecificHeapAllocator{

public:

 …

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

return static_cast<pointer>(Heap::alloc(numObjects*sizeof(T), localityHint));

 }

 void deallocate(pointer ptrToMemory, size_type numObjects) {

Heap::dealloc(ptrToMemory);

 }

 …

};

Затем

SpecialHeapAllocator

группирует элементы контейнеров:

vector<int, SpecificHeapAllocator<int, Heap1> > v; // Разместить элементы

set<int, SpecificHeapAllocator<int, Heap1> > s; // v и s в Heapl

list<Widget,

 SpecificHeapAllocator<Widget, Heap2> > L; // Разместить элементы

map<int, string, less<int>, // L и m в Heap2

SpecificHeapAllocator<pair<const int, string>, Heap2> > m;

В приведенном примере очень важно, чтобы

Heap1

и

Неар2

были типами, а не объектами. В STL предусмотрен синтаксис инициализации разных контейнеров STL разными объектами распределителей одного типа, но я не буду его приводить. Дело в том, что если бы

Heap1

и

Неар2

были бы объектами вместо типов, это привело бы к нарушению ограничения эквивалентности, подробно описанного в совете 10.

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

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

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