Комментарии 3
Один момент, который смущает — это хранение указателя на аллокатор в каждом объекте. Для контейнеров такой overhead может быть незаметен, а вот для строк — это плюс одна треть к размеру объекта. Вот думаю, можно ли провести оптимизация: хранить указатель на аллокатор в статической области памяти (thread_local). И перед работой с контейнером назначать этот указатель на необходимый аллокатор. Есть ли у кого подобный опыт?
Плюс с размером там не все так однозначно — в некоторых реализациях делают буфер прямо в самой переменной, чтобы короткие строки не ходили за памятью в кучу.
И вообще всегда можно было взять старый тип и специализировать его типом аллокатора, который как раз и ходит в thread storage, чтобы получить инстанс алокатора для текущего треда.
Эх, отвечаю, скорее всего, довольно запоздало, но тем не менее. Обычный std::basic_string (да и остальные контейнеры в STL) хранит тип, соответствующий требованиям, предъявляемым к аллокаторам. Если взять std::allocator, то по сути он просто имеет парочку методов типа allocate/deallocate и construct/destroy, а внутри никаких данных в виде полей он не содержит. В таком случае накладные расходы для его использования минимальны: 1 байт. Да и от этих накладных расходов разработчики реализаций STL уходят, используя empty-base optimization. Например, Microsoft использует свой _Compressed_pair, gcc объявляет структуру _Alloc_hider, которая делает примерно то же самое, что и _Compressed_pair (но, по моему скромному мнению, немного хуже, чем Microsoft). Вот и получается, что в обычной имплементации это работает несколько лучше.
Полиморфные аллокаторы C++17