C++ - передающие ссылки на станд.:: shared_ptr или повышение:: shared_ptr

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

Я предположу, что Вы знакомы с преждевременная оптимизация и просите у этого или академические цели или потому что Вы изолировали некоторый существующий ранее код, который показывает низкие результаты.

Передача ссылкой хорошо

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

Вы не из-за опасности потери указателя из-за использования ссылки. Та ссылка является доказательством, что у Вас есть копия интеллектуального указателя ранее в стеке, и только один поток владеет стеком вызовов, так, чтобы существующая ранее копия не уходила.

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

Вы должны всегда стараться не хранить Ваш интеллектуальный указатель как ссылка. Ваш Class::take_copy_of_sp(&sp) пример показывает корректное использование для этого.

Я избежал бы "простой" ссылки, если функция explicitely не может изменить указатель.

А const & может быть разумной микрооптимизацией при вызывании небольших функций - например, включить дальнейшую оптимизацию, как встраивание далеко некоторых условий. Кроме того, инкремент/декремент - так как это ориентировано на многопотоковое исполнение - является точкой синхронизации. Я не ожидал бы, что это будет иметь большое значение в большинстве сценариев, все же.

Обычно необходимо использовать более простой стиль, если у Вас нет причины не к. Затем или используйте const & последовательно или добавьте комментарий относительно почему при использовании его только в нескольких местах.

Во втором случае, делая это более просто:

Class::only_work_with_sp(foo &sp)
{    
    ...  
    sp.do_something();  
    ...  
}

можно назвать его как

only_work_with_sp(*sp);

Разумно передать shared_ptr с const&. Это вряд ли доставит неприятности (кроме маловероятного случая, что ссылаемый shared_ptr удален во время вызова функции, как детализировано Earwicker), и это, вероятно, будет быстрее, если Вы раздадите многие из них. Помните; значение по умолчанию boost::shared_ptr ориентировано на многопотоковое исполнение, так копирует, оно включает ориентированный на многопотоковое исполнение инкремент.

Попытка использовать const&, а не всего &, потому что временные объекты не могут быть переданы ссылкой неконстанты. (Даже при том, что расширение языка в MSVC позволяет Вам делать это так или иначе)

Да, взятие ссылки прекрасно там. Вы не намереваетесь дать совместно использованное владение метода; это только хочет работать с ним. Вы могли взять ссылку для первого случая также, так как Вы копируете его так или иначе. Но для первого случая, это берет владение. Существует этот прием для тихого копирования его только однажды:

void ClassA::take_copy_of_sp(boost::shared_ptr<foo> sp) {
    m_sp_member.swap(sp);
}

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

<час>

Редактирование : Конечно, как другие указывают, это только верно, если Вы знаете свой код и знаете, что не сбрасываете переданный общий указатель в некотором роде. Если в сомнении, просто передайте значением.

Я отговорил бы от этой практики, если Вы и другие программисты, с которыми Вы работаете действительно, действительно , не знаете то, что Вы все делаете.

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

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

Если предположить, что нас не волнует корректность const (или, более того, вы хотите позволить функциям изменять или разделять владение передаваемыми данными), передача boost::shared_ptr по значению безопаснее, чем передача по ссылке, поскольку мы позволяем исходному boost::shared_ptr контролировать свое собственное время жизни. Рассмотрим результаты следующего кода...

void FooTakesReference( boost::shared_ptr< int > & ptr )
{
    ptr.reset(); // We reset, and so does sharedA, memory is deleted.
}

void FooTakesValue( boost::shared_ptr< int > ptr )
{
    ptr.reset(); // Our temporary is reset, however sharedB hasn't.
}

void main()
{
    boost::shared_ptr< int > sharedA( new int( 13 ) );
    boost::shared_ptr< int > sharedB( new int( 14 ) );

    FooTakesReference( sharedA );

    FooTakesValue( sharedB );
}

Из примера выше видно, что передача sharedA по ссылке позволяет FooTakesReference сбросить исходный указатель, что уменьшает его счетчик использования до 0, уничтожая его данные. FooTakesValue, однако, не может сбросить исходный указатель, гарантируя, что данные sharedB все еще можно использовать. Когда неизбежно появляется другой разработчик и пытается воспользоваться хрупким существованием sharedA, начинается хаос. Счастливый разработчик sharedB, однако, рано уходит домой, поскольку в его мире все в порядке.

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

Я бы поддержал передачу общего указателя по константной ссылке - семантика, согласно которой функция, передаваемая с указателем, НЕ владеет указателем, что является чистой идиомой для разработчиков.

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

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

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

Всего 2 цента: -)