Пожалуйста, не пытайтесь вникать в смысл последней фразы. Вместо этого просто рассмотрите следующий фрагмент и переходите к дальнейшему объяснению:
template<typename T>
class allocator {
public:
template<typename U>
struct rebind{
typedef allocator<U> other;
};
…
}
В программе, реализующей list<T>, возникает необходимость определить тип распределителя ListNode, соответствующего распределителю, существующему для T. Тип распределителя для T задается параметром allocator. Учитывая сказанное, тип распределителя для ListNode должен выглядеть так:
Allocator::rebind<ListNode>::other
А теперь будьте внимательны. Каждый шаблон распределителя A (например, std::allocator, SpecialAllocator и т. д.) должен содержать вложенный шаблон структуры с именем rebind. Предполагается, что rebind получает параметр U и не определяет ничего, кроме определения типа other, где other — просто имя для A<U>. В результате list<T> может перейти от своего распределителя объектов T(Allocator) к распределителю объектов ListNode по ссылке Allocator::rebind<ListNode>::other.
Может, вы разобрались во всем сказанном, а может, и нет (если думать достаточно долго, вы непременно разберетесь, но подумать придется — знаю по своему опыту). Но вам как пользователю STL, желающему написать собственный распределитель памяти, в действительности не нужно точно понимать суть происходящего. Достаточно знать простой факт: если вы собираетесь создать распределитель памяти и использовать его со стандартными контейнерами, ваш распределитель должен предоставлять шаблон rebind, поскольку стандартные шаблоны будут на это рассчитывать (для целей отладки также желательно понимать, почему узловые контейнеры T никогда не запрашивают память у распределителей объектов T).
Ура! Наше знакомство со странностями распределителей памяти закончено. Позвольте подвести краткий итог того, о чем необходимо помнить при программировании собственных распределителей памяти:
• распределитель памяти оформляется в виде шаблона с параметром T, представляющим тип объектов, для которых выделяется память;
• предоставьте определения типов pointer и reference, но следите за тем, чтобы pointer всегда был эквивалентен T*, а reference — T&;
• никогда не включайте в распределители данные состояния уровня объекта. В общем случае распределитель не может содержать нестатических переменных;
• помните, что функциям allocate передается количество объектов, для которых необходимо выделить память, а не объем памяти в байтах. Также помните, что эти функции возвращают указатели T* (через определение типа pointer) несмотря на то, что ни один объект T еще не сконструирован;
• обязательно предоставьте вложенный шаблон rebind, от наличия которого зависит работа стандартных контейнеров.
Написание собственного распределителя памяти обычно сводится к копированию приличного объема стандартного кода и последующей модификации нескольких функций (в первую очередь allocate и deallocate). Вместо того чтобы писать базовый код с самого начала, я рекомендую воспользоваться кодом с web-страницы Джосаттиса [23] или из статьи Остерна «What Are Allocators Good For?» [24].
Материал, изложенный в этом совете, дает представление о том, чего не могут сделать распределители памяти, но вас, вероятно, больше интересует другой вопрос — что они могут? Это весьма обширная тема, которую я выделил в совет 11.
Совет 11. Учитывайте область применения пользовательских распределителей памяти
Итак, в результате хронометража, профилирования и всевозможных экспериментов вы пришли к выводу, что стандартный распределитель памяти STL (то есть allocator<T>) работает слишком медленно, напрасно расходует или фрагментирует память, и вы лучше справитесь с этой задачей. А может быть, allocator<T> обеспечивает безопасность в многопоточной модели, но вы планируете использовать только однопоточную модель и не желаете расходовать ресурсы на синхронизацию, которая вам не нужна. Или вы знаете, что объекты некоторых контейнеров обычно используются вместе, и хотите расположить их рядом друг с другом в специальной куче, чтобы по возможности локализовать ссылки. Или вы хотите выделить блок общей памяти и разместить в нем свои контейнеры, чтобы они могли использоваться другими процессами. Превосходно! В каждом из этих сценариев уместно воспользоваться нестандартным распределителем памяти.
Предположим, у вас имеются специальные функции для управления блоком общей памяти, написанные по образцу malloc и free:
void* mallocShared(size_t bytesNeeded);
void freeShared(void *ptr);
Требуется, чтобы память для содержимого контейнеров STL выделялась в общем блоке. Никаких проблем:
template<typename T>
class SharedMemoryAllocator {
public:
…
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 при управлении памятью:
