Каковы соображения производительности при использовании std :: vector> или повысить :: ptr_vector <Base>?

Question

Преимущества наличия вектора умных указателей с подсчетом ссылок многочисленны.Мне больше не нужно беспокоиться об очистке памяти, и я даже могу хранить указатели на производные классы в контейнере, и они также будут обрабатываться очень хорошо.

Это все действительно замечательно, но меня удивляето последствиях.Если мой контейнер способен корректно очищать указатели на производные классы, которые я, возможно, вставил в него, это означает, что должен иметь место какой-то RTTI.Будет ли это стоить, даже если я никогда не помещу указатели производных классов в контейнер?

Answer 1

Мой обычный совет для большинства вопросов о производительности:

• Вопросы производительности, вероятно, не перевешивают другие проблемы, такие как создание простого, простого кода
• Если вы все еще думаете, что они могут быть важными (или вам просто любопытно), вы не можете надежно думать по-вашему, ответ: вам действительно нужно измерить это. *

Как сказал другой ответ, здесь нет никакого RTTI; когда счетчик ссылок падает до нуля, shared_ptr просто вызывает delete, уничтожая ваш объект обычным способом. (или это делает что-то фактически эквивалентное)

Любые связанные с производительностью последствия должны быть в значительной степени ограничены просто различиями между T* и shared_ptr<T>. (хотя я не знаком с ptr_vector ....)

Answer 2

RTTI нет, просто прямой полиморфизм. Если ваша иерархия классов уже полиморфна (т. Е. Имеет виртуальные деструкторы и т. Д.), То от полиморфизма дополнительных затрат не возникает.

Что вам стоит беспокоить, так это стоимость общего указателя. Если возможно, посмотрите, действительно ли достаточно unique_ptr<Base>. Обновление атомарного подсчета ссылок общего указателя, возможно, является незначительной стоимостью.