Использование умных указателей в C++ в качестве параметров

Этот пост является переводом статьи Герба Саттера: GotW #91 Solution: Smart Pointer Parameters.

Постановка проблемы

Простой вопрос

1. Каковы недостатки с точки зрения производительности следующего объявления функции? Объясните.

void f( shared_ptr<widget> );

Вопросы посложнее

2. Каковы недостатки с точки зрения корректности объявления функции из вопроса 1?

3. Ваш коллега реализует функцию f, которая принимает объект класса widget в качестве обязательного параметра, предназначенного только для чтения, и пытается выбрать из следующих возможных способов передать параметр (опустим ключевое слово const):

void f( widget* );             (a)
void f( widget& );             (b)
void f( unique_ptr<widget> );  (c)
void f( unique_ptr<widget>& ); (d)
void f( shared_ptr<widget> );  (e)
void f( shared_ptr<widget>& ); (f)

Для каких ситуаций какой способ подходит? Объясните свой ответ и укажите в каких случаях и куда конкретно стоит также добавить const к типу параметра. (Есть и другие способы передать параметр, но мы рассмотрим только представленные выше.)

Решение

1. Каковы недостатки с точки зрения производительности следующего объявления функции? Объясните.

void f( shared_ptr<widget> );

Объект shared_ptr содержит счетчики сильных и слабых ссылок (см. GotW #89 Solution: Smart Pointers, перевод). Когда вы передаете объект по значению, происходит копирование аргумента (обычно) при вызове функции и уничтожение копии (всегда) при завершении функции. Давайти посмотрим внимательнее, что это значит.
Когда вы вызываете функцию, создается (с помощью конструктора копирования) новый объект shared_ptr, что влечет за собой увеличение счетчика сильных ссылок. (Да, если передается временный объект shared_ptr, то используется конструктор перемещения и счетчик ссылок не увеличивается. Но: (а) временные объекты shared_ptr достаточно редко встречаются в обычном коде, кроме как в случае передачи объекта, который только что был возвращен другой функцией; и (b) кроме этого, как мы увидим в дальнейшем, наиболее дорогостоящей является операция разрушения объекта.)
Когда функция завершается, объект shared_ptr разрушается, что влечет за собой уменьшение счетчика ссылок.
Что такого плохого в "увеличении и уменьшении счетчика ссылок"? Две вещи, одна касается "счетчика ссылок" а другая "увеличения и уменьшения". Надо понимать, как это все влияет на производительность по двум причинам: одна из них главная и достаточно распостранена, другая менее распостранена в хорошо спроектированном коде и поэтому, возможно, не такая важная.
Первая и главная причина это влияние на производительность, вызванные "увеличением и уменьшением": так как счетчик ссылок это разделяемая переменная, реализованная с помощью atomic (или с помощью чего-то аналогичного), операции увеличения и уменьшения счетчика ссылок являются синхронизованными операциями типа "чтение-изменение-запись" (internally synchronized read-modify-write operations) над разделяемой памятью.
Вторая, менее важная и более редкая причина это конкурентная природа "разделяемого счетчика ссылок", мешающая масштабируемости: обе операции, увеличение и уменьшение счетчика, обновляют счетчик ссылок. Это означает, что на уровне процессора и памяти только одно процессорное ядро в определнный момент времени может производить одну из этих операций на одном счетчике ссылок, так как ядру для этого необходим эксклюзивный доступ к блоку данных (кэш-линии) в котором содержится счетчик. В результате это вызывает некоторую конкуренцию за кэш-линию, в которой содержится счетчик, что может затруднить масштабируемость, если это популярная кэш-линия, доступ к которой требуется многим потокам внутри высокозагружающих циклов (циклов с малым количеством инструкций внутри итерации и большим количеством итераций). Например, если два потока вызывают функцию с указанным прототипом в своих циклах и передавая в нее объекты shared_ptr, которые хранят указатели на один и тот же объект. Мы могли бы правомерно заявить: "не делай так, безумец!". Очень хорошо, но не всегда может быть известно, когда два объекта shared_ptr, используемые в двух разных потоках, хранят указатели на один и тот же объект, так что давайте не будем судить слишком поспешно.
Как мы увидим, действительно ценным принципом при работе с любым умным указателем с подсчетом ссылок является следующий: избегайте копирования умного указателя кроме тех случаев, когда вы действительно хотите увеличить счетчик ссылок. Эта рекомендация не может быть переоценена. Она напрямую касается обеих рассмотренных выше проблем и снижает возможные потери производительности вызванные ими в большинстве случаев до уровня погрешности. И, что особенно важно, позволяет полностью устранить вторую проблему (так как, вообще говоря, это анти-шаблон - изменять счетчик ссылок в высокозагружающих циклах).
В данный момент высоко искушение решить проблему передавая умный указатель по ссылке. Но действительно ли это - правильное решение? Зависит от обстоятельств.

2. Каковы недостатки с точки зрения корректности объявления функции из вопроса 1?

Единственным недостатком с точки зрения корректности является то, что функция явным образом объявляет, что она будет (или могла бы) хранить копию объекта shаrеd_ptr.
Некоторых может удивить, что это и есть единственный недостаток с точки зрения корректности, так как, казалось бы, копирование аргумента функции является скорее достоинством, а именно, оно гарантирует определенное время жизни. Действительно, если предположить, что указатель в передаваемом объекте shared_ptr не нулевой, копирование этого параметра гарантирует то, что функция владеет сильной ссылкой на объект, на который ссылается указатель, и поэтому этот объект не будет уничтожен до выхода из тела функции или пока функция сама не решит изменить свой параметр.
Однако мы и так получили бы это без дополнительных издержек - благодаря структурированным временам жизни. Время жизни объектов внутри вызываемой функции всегда является частью времени жизни объектов внутри вызывающей функции. Даже если мы передаем объект shared_ptr по ссылке, это так же надежно, как если бы мы скопировали его, увеличив счетчик сильных ссылок, потому что вызывающая функция уже имеет сильную ссылку на объект, на который ссылается указатель, и она не уменьшит счетчик ссылок до того, как завершится выполнение внутренней функции. (Заметим, что предполагается, что на объект, на который ссылается передаваемый умный указатель, ссылается только этот указатель. Надо быть осторожным с ситуацией, когда два умных указателя ссылаются на один и тот же объект (pointer aliasing), но подобная ситуация ничем не будет отличаться от такой же с обычными указателями).

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

Рекомендация: предпочитайте передавать объект в функцию по значению или по ссылке (с помощью * или &).

Если вы сейчас подумали: "Эй, а разве обычные указатели - это не зло?", то это замечательно, потому что мы сейчас к этому перейдем.

3. Ваш коллега реализует функцию f, которая принимает объект класса widget в качестве обязательного параметра, предназначенного только для чтения, и пытается выбрать из следующих возможных способов передать параметр (опустим ключевое слово const). Для каких ситуаций какой способ подходит? Объясните свой ответ и укажите в каких случаях и куда конкретно стоит также добавить const к типу параметра.

(a) и (b): предпочитайте передавать параметры с помощью & или *

void f( widget* );             (a)
void f( widget& );             (b)

Это предпочтительные способы передачи обычных объектов в качестве параметров, так как в этом случае вызываемая функция никак не влияет на время жизни объектов.
Сырые невладеющие указатели * и ссылки & подходят для передачи объектов, про вреемя жизни которых известно, что оно превосходит время жизни указателя или ссылки на объект. Что обычно верно для параметров функции. Благодаря структурированным временам жизни, по умолчанию аргументы, переданные в f, проживут до завершения функцции f, что очень полезно (чтобы не сказать эффективно), и делает "сырые" указатели * и ссылки & подходящими аргументами для передачи объекта в качестве параметра.
Передавайте параметры с помощью * или & чтобы оперировать с объектом widget вне зависимости от того, как вызывающая функция управляет временем жизни этого объекта. В большинстве случаев мы не хотим влиять на время жизни объекта, передаваемого через параметр, например, передавая его с помощью умного указателя, потому что обычно в этом нет необходимости, но это влечет за собой дополнительные издержки. Как обычно, используйте *, если вам нужно обрабатывать случай с null (нет объекта widget), в остальных случаях используйте &; если объект передается только для чтения, используйте const widget* и const widget&.
(c) передача unique_ptr по значению означает "sink" (англ sink - "сливать")

void f( unique_ptr<widget> );  (c)

Это предпочтительный способ описать функцию, которая забирает widget у вызывающей, такую функцию еще называют "sink".
Передача unique_ptr по значению возможно только через перемещение объекта и передачу уникального владения им из вызывающей функции в вызываемую. Любая функция типа (с) забирает владение объектом widget у вызывающей функции и либо разрушает объект, либо передает его вместе с владением куда-то еще.
Отметим, что, в отличие от вариантов ниже, способ передачи параметра через unique_ptr по значению на самом деле позволяет передавать не только объекты, управляемые unique_ptr. Почему? Потому что любой указатель может быть явно приведен к типу unique_ptr. Если бы мы не использовали здесь unique_ptr, нам бы все равно пришлось описать семантику типа "sink" но гораздо более ненадежным способом: например, передав сырой владеющий указатель (анафема!) и описав семантику в комментариях. Подход (c) гораздо лучше, потому что он описывает семантику с помощью кода и заставляет вызывающую функцию явным образом передать владение объектом.
Рассмотрим главную альтернативу

// Дурнопахнущая альтернатива из 20го века
void bad_sink( widget* p );  // удаляет р; ПОЖАЛУЙСТА, ПРОЧИТАЙТЕ ЭТОТ КОММЕНТАРИЙ

// Приятная самодокументирующая самозащищающаяся современная версия (c)
void good_sink( unique_ptr<widget> p );

и увидим, насколько (с) лучше:

// Старый код, вызывающий современную good_sink становится более безопасным, 
// потому что из кода понятно, что происходит передача владения.
// (В старом коде использовался владеющий сырой указатель, чего не следует делать
// в новом коде)
//
widget* pw = ... ; 

bad_sink ( pw );             // компилируется: необходимо помнить о том,
                             // что нельзя использовать pw снова!

good_sink( pw );             // ошибка компиляции: хорошо!
good_sink( unique_ptr<widget>{pw} );  // требуется явно преобразование: хорошо

// Современный код, вызывающий good_sink тоже становится более безопасным и понятным
//
unique_ptr<widget> pw = ... ;

bad_sink ( pw.get() );       // компилируется: плохо! не вызывается reset для pw
bad_sink ( pw.release() );   // компилируется: нужно помнить, что надо использовать именно так

good_sink( pw );             // ошибка компиляции: хорошо!
good_sink( move(pw) );       // компилируется: абсолютно понятно, что происходит

Рекомендация: Объявляйте функции типа sink используя передачу unique_ptr по значению.

Так как вызываемая функция теперь будет владеть объектом, обычно не нужно использовать модификатор const с параметром, так как он в данном случае не имеет смысла.
(d) Передача unique_ptr по ссылке подходит для параметров типа unique_ptr предназначенных для чтения и записи

void f( unique_ptr<widget>& ); (d)

Такой прототип должен использоваться только для передачи объекта unique_ptr предназначенного для чтения и записи, когда предполагается, что функция действительно принимает существующий unique_ptr и теоретически может его изменть так, что он будет ссылаться на другой объект. Это плохой способ просто передать объект класса widget, так как в этом случае вызывающая функция контролирует время жизни объекта.

Рекомендация: Используйте неконстантный параметр типа unique_ptr& только если необходимо изменять объект unique_ptr внутри функции.

Передавать в параметр объект const unique_ptr& довольно странно, потому что таким образом можно передать в функцию либо null, либо объект класса widget, чьим временем жизни будет управлять вызывающая функция с помощью unique_ptr. Вызываемая же функция обычно не должна знать о том, как конкретно время жизни будет управляться. Передача параметра типа widget* покрывает оба эти случая: так можно передать null или widget вне зависимости от того, как именно вызывающий код управляет временем жизни объекта.

Рекомендация: Не используйте const unique_ptr& в качестве типа параметра; вместо этого используйте widget*

Я упомянул здесь widget* потому что использование этого типа не меняет семантику. Если вы подумываете о том, чтоб использовать const widget& для передачи параметра, на самом деле вы имеете в виду widget*, так как этот тип несет в себе такую же информацию. Хотя если вы дополнительно знаете, что объект класса widget не может быть нулевым, конечно же используйте тип widget&.
(e) передача shared_ptr по значению подразумевает получение совместного владения объектом

void f( shared_ptr<widget> ); (e)

Как мы видели в пункте 2 такой способ рекомендуется только в том случае, если действительно хочет получить копию shared_ptr и владеть объектом. В этом случае копирование все равно необходимо и с затратами на копирование придется смириться. Если требуется передать указатель куда-то вне локальной области видимости, просто переместите объект shared_ptr с помощью std::move туда, куда требуется.

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

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

(f) параметры типа shared_ptr& полезны, когда требуется как чтение так и изменение shared_ptr

void f( shared_ptr<widget>& ); (f)

Так же, как и в случае (d), этот способ следует использовать, чтобы передавать объекты shared_ptr, предназначенные как для чтения, так и для записи, когда подразумевается, что функция будет изменять сам объект shared_ptr. Обычно это плохой способ просто передать объект класса widget, так как в этом случае вызывающая функция контролирует время жизни объекта.
Отметим, что в случае (e) мы передаем shared_ptr по значению, так как функция должна владеть объектом. В случае, когда функция может владеть объектом, но ей не обязательно копировать свой параметр во время каждого вызова, используйте тип параметра const shared_ptr&, чтобы избежать копирования параметра для тех вызовов функции, в которых это не нужно, и копируйте shared_ptr только по мере необходимости.

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