2.6. Аллокаторы

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

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

В этой книге мы не будет детально рассматривать аллокаторы, поскольку класса аллокатора по умолчанию, предоставляемого реализациями STL, вполне достаточно для удовлетворения большинства потребностей программистов. Те программисты, которым требуется определение новых аллокаторов, найдут в главе 24, "Справочное руководство по аллокаторам", описание информации, которую должен предоставлять аллокатор.

Глава 3. Отличие stl от других библиотек

Перед тем как перейти к более детальному рассмотрению компонентов STL в следующей главе, кратко рассмотрим основные отличия между STL и другими библиотеками C++.

Во-первых, большинство библиотек C++ содержит контейнеры, которые требуют, чтобы содержащиеся в них объекты были производными от некоторого общего предка. Контейнеры STL не опираются ни на какие предположения о наследовании; они могут хранить что угодно, включая встроенные типы.

Во-вторых, в традиционных библиотеках контейнерных классов все алгоритмы связаны с определенными классами и реализованы в качестве функций-членов. Если класс списка в такой библиотеке имеет алгоритм поиска наподобие find, то такой алгоритм будет отличаться от алгоритма поиска в классе вектора. Основная проблема такой организации заключается в том, что каждый класс библиотеки должен содержать огромное количество исходного текста и документации. При наличии m контейнеров и определенных над ними n операций

(наподобие find) вам потребуется определить и документировать m*n операций. В

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

Подход STL прошел длинный путь в поисках решения этой проблемы. Вместо m

контейнеров и m*n операций, которые следует определить и документировать, мы имеем дело только с m контейнерами и n обобщенными операциями. Так мы получаем гораздо более высокую степень гибкости в выборе алгоритмов и контейнеров, чем в случае традиционных библиотек классов, а кроме того, количество интерфейсов, которые следует изучить, и общее количество кода, которое следует поддерживать, остается достаточно небольшим.