В настоящее время я разрабатываю структуру объектов для игры, и самая естественная организация в моем случае стала деревом. Являясь отличным поклонником умных указателей, я использую shared_ptr исключительно. Однако в этом случае детям в дереве потребуется доступ к нему родительским (пример - существа на карте должны иметь возможность доступа к картографическим данным - ergo данные своих родителей).
Направление владения - это, конечно, то, что карта принадлежит этим существам, поэтому держит с ними общие указатели. Чтобы получить доступ к данным карты изнутри существа, нам, однако, нужен указатель на родителя - способ умных указателей - использовать ссылку ergo a weak_ptr.
Однако однажды я прочитал, что блокировка weak_ptr - дорогостоящая операция - может быть, это не так, - но учитывая, что weak_ptr будет заблокирован очень часто, я обеспокоен тем, что этот дизайн обречен низкая производительность.
Следовательно, вопрос:
Какова эффективность блокировки функции weak_ptr? Насколько это важно?
Из исходного кода Boost 1.42 (<boost/shared_ptr/weak_ptr.hpp> строка 155):
shared_ptr<T> lock() const // never throws
{
return shared_ptr<element_type>( *this, boost::detail::sp_nothrow_tag() );
}
ergo, комментарий Джеймса Макнеллиса правильный; это стоимость копирования-построения a shared_ptr.
для моего собственного проекта, я смог значительно улучшить производительность, добавив
#define BOOST_DISABLE_THREADS перед тем, как включить форсирование.
Это позволяет избежать накладных расходов spinlock/mutex для слабой_ptr:: lock, которая в моем проекте была
основным узким местом. Поскольку проект не поддерживает многопоточность, я мог бы это сделать.