Здравствуйте. Уже поднимал подобную тему раньше, но тогда решения не нашел, а сейчас оно снова стало актуально.
Избавляюсь от прямого использования boost в заголовках своей библиотеки. Некоторые классы оной включают очень большие количества мелких объектов, выделяемых на куче. Например, есть объект, который содержит std::list других таких же объектов, и такая иерархия образует гигантское дерево. Все эти объекты имеют одинаковый тип (не наследуются), а, значит, одинаковый размер, и мне бы логично хотелось бы складывать их в какой-то pool, а не фрагментировать кучу легионом мелких объектов. Поэтому, я обратился к сабжу. Тогда я еще везде дергал boost, поэтому включение подобных заголовков во все заголовки движка меня ни капли не смущало. Но с приходом новых версий С++ необходимость тянуть boost везде пропала, и теперь только этот аллокатор, затягивая с собой еще кучу бутовских хидеров (например, mpl!), обеспечивает мне процентов 25 всего размера препроцесснутых исходников, а, значит, и времени компиляции. Поэтому, я хочу от него избавиться. Какие варианты решения:
1. Просто про него забыть и использовать стандартный. Вроде бы на PC этот аллокатор особенного выигрыша в скорости не давал, но на мобилках разница была очень даже заметна. Замедлять работу программы ради скорости компиляции как-то не хочется.
2. Поискать в интернете замену. Там полно разных велосипедов, и у всех свои неоспоримые преимущества и свои неустранимые баги. И у всех разная совместимость с разными компиляторами и архитектурами. Не хотелось бы влипнуть в какую-то несовместимость в самый неподходящий момент.
3. Написать самому. Я не уверен, что у меня достаточно компетенции, чтобы сходу написать что-то, что будет работать настолько быстро и устойчиво, чтобы заменить стандартный аллокатор из STL.
Что посоветуете? Меня бы устроил простейший (даже однопоточный, так даже лучше) хидер-онли аллокатор, написаный без сложных платформенных вывертов, заточенный под хранение и частое удаление / создание мелких объектов равного размера, исключающий при этом постоянное непосредственно обращение к операциям кучи. Грубо говоря, "выделяю чанк на 1024 объекта указанного размера, и, если места не хватит, выделяю новый". Все.