Чи слід передавати shared_ptr за посиланням або за значенням?

Коли функція приймає shared_ptr(від boost або C ++ 11 STL), ви передаєте її:

• за посиланням const: 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 за значенням.

Керівництво: Використовуйте параметр non-const shared_ptr & only лише для зміни 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 :: переміщувати 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, порада від Herb Sutter:

Використовуйте const shared_ptr & як параметр лише в тому випадку, якщо ви не впевнені, чи будете ви копіювати та надавати право власності

Але в скільки випадків ви не впевнені? Тож це рідкісна ситуація

Відомо питання про те, що передача shared_ptr за значенням має вартість і слід уникати, якщо це можливо.

Вартість проїзду через shared_ptr

Більшу частину часу проходив би shared_ptr за посиланням, а ще краще за посиланням const.

Основна інструкція cpp має специфічне правило для передачі shared_ptr

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

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

Приклад, коли передача shared_ptr за значенням дійсно необхідна, це те, коли абонент передає спільний об'єкт асинхронному виклику, тобто той, хто викликає, виходить за межі до того, як виклик завершить свою роботу. Оголошення повинне "продовжити" термін експлуатації спільного об'єкта, прийнявши share_ptr за значенням. У цьому випадку передавання посилання на shared_ptr не обійдеться.

Те саме стосується передачі спільного об'єкта в робочу нитку.

shared_ptr недостатньо великий, а також його конструктор \ destructor не роблять достатньо роботи, щоб було достатньо накладних витрат з копії, щоб дбати про пропуск посилання на пропуск при виконанні копії.