Любое попадание для разыменования std :: tr1: shared_ptr против разыменования голого указателя?

Question

Я понимаю, что есть (иногда значительное) снижение производительности при создании, назначении, копировании и уничтожении std :: tr1 :: shared_ptr или boost :: shared_ptr (из-за механизмов подсчета ссылок).Правильно ли, что после создания доступ к указателю, обернутому shared_ptr, не снижает производительности?те же накладные расходы, что и

NakedA->someClassMember

?

Answer 1

В оптимизированной сборке без поддержки отладки не должно быть никаких накладных расходов.Вы можете узнать это, взглянув на реализацию, которую вы используете.Скорее всего, перегрузка operator-> просто возвращает указатель на объект, на который указывает указатель, а перегрузка operator* просто разыменовывает этот указатель.

(Вот что делает реализация std::shared_ptr в Visual C ++ 2010:каждый из этих перегруженных операторов просто вызывает функцию «get», которая просто возвращает указатель; блокировка или другие издержки отсутствуют. Другие реализации могут отличаться.)

Неоптимизированная сборка может не включать операторПерегрузка, и если ваша реализация имеет дополнительную поддержку отладки, которую вы включаете, она может выполнять дополнительные проверки (например, возможно, утверждение, если вы разыменовываете нулевой указатель).

Answer 2

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