Зачем мне std :: переместить std :: shared_ptr?

Я просматривал исходный код Clang и нашел этот фрагмент:

void CompilerInstance::setInvocation(
    std::shared_ptr<CompilerInvocation> Value) {
  Invocation = std::move(Value);
}

Зачем мне std::moveэто std::shared_ptr?

Есть ли смысл передавать право собственности на общий ресурс?

Почему бы мне просто не сделать это вместо этого?

void CompilerInstance::setInvocation(
    std::shared_ptr<CompilerInvocation> Value) {
  Invocation = Value;
}

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

std::shared_ptrсчетчик ссылок атомный . увеличение или уменьшение счетчика ссылок требует атомного увеличения или уменьшения . Это в сто раз медленнее, чем неатомарное увеличение / уменьшение, не говоря уже о том, что если мы увеличиваем и уменьшаем один и тот же счетчик, мы получаем точное число, тратя на это массу времени и ресурсов.

Перемещая shared_ptrвместо копирования его, мы «крадем» атомный счетчик ссылок и обнуляем другой shared_ptr. «кража» счетчика ссылок не является атомарной , и она в сто раз быстрее, чем копирование shared_ptr(и вызывает увеличение или уменьшение атомной ссылки).

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

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

Операции перемещения (например, конструктор перемещения) для std::shared_ptrявляются дешевыми , поскольку они в основном являются «крадящими указателями» (от источника к месту назначения; точнее, весь блок управления состоянием «украден» от источника к месту назначения, включая информацию о количестве ссылок) ,

Вместо этого операции копирования при std::shared_ptrвызове увеличивают атомный счетчик ссылок (т.е. не только ++RefCountдля целочисленного RefCountчлена данных, но, например, при вызове InterlockedIncrementв Windows), что дороже, чем просто кража указателей / состояний.

Итак, детально анализируя динамику подсчета ссылок в этом случае:

// shared_ptr<CompilerInvocation> sp;
compilerInstance.setInvocation(sp);

Если вы передаете spпо значению, а затем берете копию внутри CompilerInstance::setInvocationметода, у вас есть:

1. При входе в метод shared_ptrпараметр создается с помощью копии: ref count атомарный инкремент .
2. Внутри тела метода, вы скопировать в shared_ptrпараметр в элементе данных: ЗАДАНИЕ рассчитывать атомное приращение .
3. При выходе из метода shared_ptrпараметр разрушается: ref count атомарный декремент .

У вас есть два атомных приращения и один атомарный декремент, всего три атомарных операции.

Вместо этого, если вы передадите shared_ptrпараметр по значению, а затем std::moveвнутри метода (как это правильно сделано в коде Кланга), вы получите:

1. При входе в метод shared_ptrпараметр создается с помощью копии: ref count атомарный инкремент .
2. Внутри тела метода, вы параметр в элемент данных: исх счетчик ничего не изменится! Вы просто крадете указатели / состояния: дорогостоящие операции по подсчету атомных ссылок не требуются.std::moveshared_ptr
3. При выходе из метода shared_ptrпараметр уничтожается; но поскольку вы перешли на шаге 2, уничтожать нечего, так как shared_ptrпараметр больше ни на что не указывает. Опять же, в этом случае не происходит атомного декремента.

Итог: в этом случае вы получаете только один атомный инкремент подсчета ссылок, т.е. только одну атомарную операцию.
Как вы можете видеть, это намного лучше, чем два атомарных приращения плюс один атомарный декремент (всего три атомарных операции) для случая копирования.

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

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

Для std :: shared_ptr std :: move однозначно обозначает передачу права владения pointee, тогда как простая операция копирования добавляет дополнительного владельца. Конечно, если первоначальный владелец впоследствии отказывается от своего права собственности (например, разрешив уничтожить его std :: shared_ptr), тогда передача права собственности была завершена.

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

По крайней мере, с libstdc ++ вы должны получить одинаковую производительность с перемещением и назначением, поскольку operator=вызывает std::moveвходящий указатель. Смотрите: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr.h#L384