LINUX.ORG.RU

История изменений

Исправление dzidzitop, (текущая версия) :

vector::resize - это new, copy, delete; realloc - это или malloc/copy/free или просто увеличение менеджером памяти размера буфера, если память за выделенным уже куском свободна и размер её достаточен.

кастомные аллокаторы писать не доводилось. там, где понадобится - будет что-то типа как в контейнерах stl с кастомными аллокаторами. только там много нюансов, так что может проще будет пул объектов статический сделать.

а сейчас у я пользуюсь обёртками над malloc/free, которые позволяют передавать память между структурами. а то, что все куски выделены единообразно, позволяет освобождать память через free() и не париться. количество аллокаций памяти минимальны, и париться с абстракцией new/delete (где нет гарантий) не хочется.

типичный пример - создал буфер с динамическим размером, назаписывал туда нужной инфы - передал потом буфер как строку неизменного размера, вместо ненужных аллокаций и копирований. и взаимодействие с C кодом отличное.

так что всё это очень зависит от ситуации. но там, где хочется производительности, там места std::vector и всяким там std::string обычно нет. достаточно посмотреть на STL алгоритмы - отличный стиль того, как можно работать со всем вместе без оверхеда из-за того, что контейнеры светятся в API.

Исходная версия dzidzitop, :

vector::resize - это new, copy, delete; realloc - это или malloc/copy/free или просто увеличение менеджером памяти размера буфера, если память за выделенным уже куском свободна и размер её достаточен.

кастомные аллокаторы писать не доводилось. там, где понадобится - будет что-то типа как в контейнерах stl с кастомными аллокаторами. только там много нюансов, так что может проще будет пул объектов статический сделать.

а сейчас у я пользуюсь обёртками над malloc/free, которые позволяют передавать память между структурами. а то, что все куски выделены единообразны, позволяет освобождать память через free() и не париться. количество аллокаций памяти минимальны, и париться с абстракцией new/delete (где нет гарантий) не хочется.

типичный пример - создал буфер с динамическим размером, назаписывал туда нужной инфы - передал потом буфер как строку неизменного размера, вместо ненужных аллокаций и копирований. и взаимодействие с C кодом отличное.

так что всё это очень зависит от ситуации. но там, где хочется производительности, там места std::vector и всяким там std::string обычно нет. достаточно посмотреть на STL алгоритмы - отличный стиль того, как можно работать со всем вместе без оверхеда из-за того, что контейнеры светятся в API.