std :: string без распределения свободной памяти для хранилища

У меня вопрос, очень похожий на

Как мне разместить std :: string в стеке с помощью строковой реализации glibc?

но я думаю, что это того стоит спрашиваю снова.

Я хочу std :: string с локальным хранилищем, которое переполняется в бесплатное хранилище. std :: basic_string предоставляет распределитель в качестве параметра шаблона, поэтому кажется, что нужно написать распределитель с локальным хранилищем и использовать его для параметризации basic_string , например:

std::basic_string<
char, 
std::char_traits, 
inline_allocator 
> 
x("test");

Я пробовал чтобы написать класс inline_allocator , который работал бы ожидаемым образом: он резервирует 10 байтов для хранения, а если basic_string требует более 10 байтов, он вызывает :: оператор new () . Я не мог заставить его работать. В ходе выполнения приведенной выше строки кода моя стандартная строковая библиотека GCC 4.5 вызывает конструктор копирования для inline_allocator 4 раза. Мне не ясно, есть ли разумный способ написать конструктор копирования для inline_allocator .

В другом потоке StackOverflow, Эрик Мельски предоставил эту ссылку на класс в Chromium:

http://src.chromium.org/svn/trunk/src/base/stack_container.h

, что интересно, но не является заменой для std :: string , поскольку он оборачивает std :: basic_string в контейнер, так что вам нужно вызвать перегруженный оператор -> () , чтобы получить в std :: basic_string .

Я не могу найти других решений этой проблемы. Может быть, нет хорошего решения? И если это правда, то являются ли концепции std :: basic_string и std :: allocator сильно ошибочными? Я имею в виду, похоже, что это должен быть очень простой и простой вариант использования для std :: basic_string и std :: allocator . Я полагаю, что std :: Концепция распределителя разработана в первую очередь для пулов, но я думаю, что она должна также охватить и это.

Похоже, что семантика перемещения rvalue-reference в C ++ 0x могла бы позволить написать inline_allocator , если строковая библиотека переписана так, что basic_string использует конструктор перемещения своего распределителя вместо конструктора копирования. Кто-нибудь знает, каковы перспективы такого результата?

Моему приложению необходимо создавать миллион крошечных строк ASCII в секунду, поэтому я написал свой собственный класс строк фиксированной длины на основе Boost.Array , который работает нормально, но меня это все еще беспокоит.