С++ 17 принесет нам std::pmr::memory_resource, который является чистым интерфейсом для выделения и освобождения памяти. В отличие от концепции Allocator, она делает именно это и не более того. Также будет std::pmr::polymorphic_allocator, который переносит ресурс памяти в классический распределитель, поэтому его можно использовать с существующими контейнерами.
Если я собираюсь написать новый контейнер (или другой, голодный память) тип таргетинга на С++ 17 и более поздний, должен ли я продолжить программирование против концепции Allocator или, скорее, использовать более новую и более чистую абстракцию напрямую?
На данный момент мои мысли идут так.
Причины продолжения использования распределителей:
- Это соответствует стандартной библиотеке и существующему коду. Даже новые псевдонимы
std::pmr::*продолжают использовать распределители. - Поскольку ресурс памяти может быть обернут в
std::pmr::polymorphic_allocator, интерфейс распределителя более общий и удовлетворяет потребности большего числа клиентов. - Ресурсы памяти всегда используют полиморфизм во время выполнения, поэтому они имеют незначительную дополнительную временную нагрузку по сравнению с абстракцией нулевой накладной, которую могут предоставить распределители.
- Возможно, кому-то действительно нужны другие части интерфейса распределителя (такие как пользовательские типы указателей), которые не могут быть предоставлены чистым ресурсом памяти.
Причины использования ресурсов памяти вместо распределителей:
- Интерфейс распределителя является неудобным и трудно реализуемым. Интерфейс
std::pmr::memory_resourceчистый и прямой. - Поскольку ресурсы памяти являются полиморфными, они не влияют на тип контейнера, что означает меньшее количество экземпляров шаблонов (и, следовательно, возможно, более быстрые компиляции и меньшие исполняемые файлы) и позволяет нам перемещать больше кода в отдельные единицы перевода.
- Если объект использует ресурс памяти, он всегда может создавать экземпляр под-объекта, который все еще использует распределители, путем переноса ресурса памяти в
std::pmr::polymorphic_allocator. Другой путь более сложный. - В любом случае распределение памяти является относительно трудоемкой задачей. Один вызов виртуальной функции не требует значительных накладных расходов, относительно говоря.
Существуют ли какие-либо рекомендации по эффективному использованию новой функции библиотеки?
