Обратите внимание: эта проблема возникает на стадии выполнения. Распределители, обладающие состоянием, компилируются вполне нормально — просто они не работают так, как предполагалось. За эквивалентностью всех однотипных распределителей вы должны следить сами. Не рассчитывайте на то, что компилятор предупредит о нарушении этого ограничения.

Справедливости ради стоит отметить, что сразу же за положением об эквивалентности однотипных распределителей памяти в Стандарт включен следующий текст: «…Авторам реализаций рекомендуется создавать библиотеки, которые… поддерживают неэквивалентные распределители. В таких реализациях… семантика контейнеров и алгоритмов для неэквивалентных экземпляров распределителей определяется самой реализацией».

Трогательное проявление заботы, однако пользователю STL, рассматривающему возможность создания нестандартного распределителя с состоянием, это не дает практически ничего. Этим положением можно воспользоваться только в том случае, если вы уверены в том, что используемая реализация STL поддерживает неэквивалентные распределители, готовы потратить время на углубленное изучение документации, чтобы узнать, подходит ли вам «определяемое самой реализацией» поведение неэквивалентных распределителей, и вас не беспокоят проблемы с переносом кода в реализации STL, в которых эта возможность может отсутствовать. Короче говоря, это положение (для особо любознательных — абзац 5 раздела 20.1.5) лишь выражает некие благие намерения по поводу будущего распределителей. До тех пор пока эти благие намерения не воплотятся в жизнь, программисты, желающие обеспечить переносимость своих программ, должны ограничиваться распределителями без состояния.

Выше уже говорилось о том, что распределители обладают определенным сходством с оператором

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

В обоих случаях передается параметр, определяющий объем выделяемой памяти, но в случае с оператором

указывается конкретный объем в байтах, а в случае с указывается количество объектов , размещаемых в памяти. Например, на платформе, где , при выделении памяти для одного числа оператору передается число 4, а — число 1. Для оператора параметр относится к типу , а для функции — к типу , В обоих случаях это целочисленная величина без знака, причем обычно является простым определением типа для . В этом несоответствии нет ничего страшного, однако разные правила передачи параметров оператору и усложняют использование готовых пользовательских версий new в разработке нестандартных распределителей.

Оператор new отличается от

и типом возвращаемого значения. Оператор возвращает , традиционный способ представления указателя на неинициализированную память в C++. Функция возвращает (через определение типа ), что не только нетрадиционно, но и отдает мошенничеством. Указатель, возвращаемый , не может указывать на объект , поскольку этот объект еще не был сконструирован! STL косвенно предполагает, что сторона, вызывающая , сконструирует в полученной памяти один или несколько объектов (вероятно, посредством , или ), хотя в случае или этого может никогда не произойти (совет 13). Различия в типах возвращаемых значений оператора и означают изменение концептуальной модели неинициализированной памяти, что также затрудняет применение опыта реализации оператора к разработке нестандартных распределителей.

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

Данная странность присуща

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

Давайте подумаем, как может выглядеть типичная реализация

. Список состоит из узлов, каждый из которых содержит объект и два указателя (на следующий и предыдущий узлы списка).