Могу ли я создать резервную навязчивую коллекцию, используя пул повышения в качестве хранилища?

Ответ — да.

Это тоже не очень типично.

Если вы хотите контролировать когда а также где память выделена, вы используете пул.

Если вы хотите отделить структуру памяти вашей структуры данных и ее семантику, вы используете навязчивый контейнер.

Итак, есть приятное место, но это будет выглядеть так:

• украсить тип элемента навязчивыми хуками (например, для навязчивой карты)
• Вы создаете новые элементы в некотором типе «оптимального» макета памяти (это может быть vector<MyElement, custom_allocator>)

Бесполезные замечания:

• затем, когда я удаляю из списка, я освобождаю, используя пул повышения

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

• объекты нуждаются в собственном управлении временем жизни

  Это звучит немного странно. Фактически, объект не должен иметь «своего» управления временем жизни. Просто их жизнь не регулируется навязчивой структурой данных, в которой они участвуют.

  Например. сохраняя все элементы в векторе, вы получаете непрерывное хранилище, а время жизни всех элементов определяется вектором^[1]. Следовательно, вы можете отделить время жизни элемента и его распределение от семантики контейнера.

^[1] любые проблемы, связанные с перераспределением вектора, обычно предотвращаются за счет резервирования достаточной емкости. Если вы это сделаете, вы поймете, что это очень похоже на распределитель пула фиксированного размера, но с дополнительной гарантией нулевой фрагментации. Если вам не нужно последнее, вы можете сделать list<T, pool_allocator<T> > Таким образом, вы получаете местность ссылки, но стабильные ссылки на вставку / удаление. И т. Д.