Должны ли мы передавать shared_ptr по ссылке или по значению?

Когда функция берет shared_ptr(из boost или C ++ 11 STL), вы передаете ее:

• по постоянной ссылке: void foo(const shared_ptr<T>& p)

• или по значению void foo(shared_ptr<T> p):?

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

Не могли бы вы привести причины вашего выбора или, если дело, почему вы думаете, что это не имеет значения.

Этот вопрос был обсужден и получен ответом Скотта, Андрея и Херба во время сессии « Спросите нас что-нибудь» на C ++ и после 2011 года . Смотрите с 4:34 о shared_ptrпроизводительности и правильности .

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

Если вы не можете переместить-оптимизировать это, как объяснено Скоттом Мейерсом в видео-ролике, связанном выше, но это связано с реальной версией C ++, которую вы можете использовать.

Главное обновление этой дискуссии произошло во время интерактивной панели конференции GoingNative 2012 : «Спросите нас о чем угодно» который стоит посмотреть, особенно с 22:50 .

Вот Херб Саттерс

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

Указание: укажите, что функция будет хранить и совместно использовать владельца объекта кучи, используя параметр shared_ptr по значению.

Рекомендация: используйте неконстантный параметр shared_ptr & только для изменения shared_ptr. Используйте const shared_ptr & в качестве параметра только в том случае, если вы не уверены, будете ли вы брать копию и передавать ее в собственность; в противном случае используйте вместо него виджет * (или, если не обнуляемый, виджет &).

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

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

Я запустил приведенный ниже код, один раз с fooпринятием shared_ptrбайта, const&и снова с fooпринятием shared_ptrзначения по

void foo(const std::shared_ptr<int>& p)
{
    static int x = 0;
    *p = ++x;
}

int main()
{
    auto p = std::make_shared<int>();
    auto start = clock();
    for (int i = 0; i < 10000000; ++i)
    {
        foo(p);
    }    
    std::cout << "Took " << clock() - start << " ms" << std::endl;
}

Использование VS2015, сборка x86, на моем процессоре Intel Core 2 Quad (2,4 ГГц)

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

Версия копирования по значению была на порядок медленнее.
Если вы вызываете функцию синхронно из текущего потока, предпочтите const&версию.

Начиная с C ++ 11, вы должны воспринимать его по значению над const и чаще, чем вы думаете.

Если вы берете std :: shared_ptr (а не базовый тип T), то вы делаете это, потому что хотите что-то с ним сделать.

Если вы хотите скопировать его куда-то, имеет смысл взять его копией и std :: переместить его внутренне, а не копировать с помощью const &, а затем скопировать позже. Это потому, что вы позволяете вызывающей опции в свою очередь вызывать std :: move shared_ptr при вызове вашей функции, тем самым сохраняя себе набор операций увеличения и уменьшения. Или не. То есть, вызывающая функция может решить, нужен ли ему std :: shared_ptr после вызова функции, и в зависимости от того, перемещать или нет. Это не достижимо, если вы проходите мимо const &, и поэтому желательно, чтобы оно принималось по значению.

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

Например, вы должны сделать

void enqueue(std::shared<T> t) m_internal_queue.enqueue(std::move(t));

над

void enqueue(std::shared<T> const& t) m_internal_queue.enqueue(t);

Потому что в этом случае вы всегда создаете копию внутри

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

По результатам моего теста, приращение и уменьшение атома int32 занимает в 2 или 40 раз больше, чем неатомарное увеличение и уменьшение. Я получил его на 3GHz Core i7 с Windows 8.1. Первый результат проявляется, когда не возникает спор, а второй - при высокой вероятности возникновения спора. Я имею в виду, что атомарные операции - это, наконец, аппаратная блокировка. Замок это замок. Плохо для производительности, когда происходит конфликт.

Испытывая это, я всегда использую byref (const shared_ptr &), а не byval (shared_ptr).

Был недавний пост в блоге: https://medium.com/@vgasparyan1995/pass-by-value-vs-pass-by-reference-to-const-c-f8944171e3ce

Таким образом, ответ на этот вопрос: (почти) никогда не проходить мимо const shared_ptr<T>&.
Просто передайте базовый класс.

В основном единственные разумные типы параметров:

• shared_ptr<T> - Изменить и взять на себя ответственность
• shared_ptr<const T> - Не изменяй, бери в собственность
• T& - Изменить, нет собственности
• const T& - Не модифицируй, не владей
• T - Не изменяйте, не владейте, Дешево копировать

Как отметил @accel в https://stackoverflow.com/a/26197326/1930508, совет Херба Саттера:

Используйте const shared_ptr & в качестве параметра, только если вы не уверены, будете ли вы брать копию и делиться правами собственности

Но в скольких случаях вы не уверены? Так что это редкая ситуация

Известна проблема, заключающаяся в том, что передача shared_ptr по значению имеет цену, и ее следует избегать, если это возможно.

Стоимость проезда по shared_ptr

Большую часть времени можно было бы передавать shared_ptr по ссылке, а еще лучше по ссылке.

В основном руководстве по cpp есть специальное правило для передачи shared_ptr

R.34: принять параметр shared_ptr, чтобы выразить, что функция является частичным владельцем

void share(shared_ptr<widget>);            // share -- "will" retain refcount

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

То же самое касается передачи общего объекта в рабочий поток.

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