なぜstd :: move an std :: shared_ptrなのでしょうか？

私はClangソースコードを調べていましたが、次のスニペットを見つけました。

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

なぜ私がしたいでしょうか？std::movestd::shared_ptr

共有リソースの所有権を譲渡するポイントはありますか？

なぜ私は代わりにこれをしないのですか？

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

他の答えが十分に強調しなかったのはスピードのポイントだと思います。

std::shared_ptr参照カウントはアトミックです。参照カウントを増減するには、アトミックインクリメントまたはデクリメントが必要です。これは、非アトミックなインクリメント/デクリメントよりも100倍遅いことは言うまでもありません。同じカウンタをインクリメントおよびデクリメントすると、正確な数になり、プロセスに大量の時間とリソースが浪費されます。

shared_ptrをコピーする代わりに移動することにより、アトミック参照カウントを「スチール」し、もう一方を無効にしshared_ptrます。参照カウントを「盗む」ことはアトミックではなく、それをコピーするshared_ptr（そしてアトミックな参照の増分または減分を引き起こす）よりも100倍高速です。

この手法は純粋に最適化のために使用されることに注意してください。（あなたが提案したように）それをコピーすることは、機能的にも同様に素晴らしいです。

を使用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 atomic increment。
2. メソッドの本体の中で、 shared_ptrパラメーターをデータメンバーにコピーします。ref count atomic increment。
3. メソッドを終了すると、 shared_ptrパラメーターは破棄されます：ref count atomic decrement。

2つのアトミックインクリメントと1つのアトミックデクリメントがあり、合計3つの アトミック操作があります。

代わりに、 shared_ptrパラメーターを値でstd::moveメソッド内で（Clangのコードで正しく行われるように）と、次のようになります。

1. メソッドを入力すると、 shared_ptrパラメーターはコピー構築されます：ref count atomic increment。
2. メソッドの本体の中で、 std::moveshared_ptrデータメンバへのパラメータは：refカウントがないではない変更します！ポインタ/状態を盗むだけです。高価なアトミック参照カウント操作は必要ありません。
3. メソッドを終了すると、shared_ptrパラメーターは破棄されます。しかし、ステップ2で移動したので、shared_ptrパラメーターがもう何も指していないため、破壊するものはありません。この場合も、アトミックデクリメントは発生しません。

結論：この場合、参照カウントのアトミック増分は1つしか得られません。つまり、アトミック操作は1つだけです。
ご覧のように、これは、コピーの場合の2つのアトミックインクリメントと1つのアトミックデクリメント（合計3つのアトミック操作）よりもはるかに優れています。

のコピーにshared_ptrは、内部状態オブジェクトポインタのコピーと参照カウントの変更が含まれます。これを移動するには、内部参照カウンターへのポインターと所有オブジェクトを交換するだけなので、より高速です。

この状況でstd :: moveを使用する理由は2つあります。ほとんどの応答は速度の問題に対処しましたが、コードの意図をより明確に示すという重要な問題を無視しました。

std :: shared_ptrの場合、std :: moveは明確に指示先の所有権の譲渡を示しますが、単純なコピー操作では追加の所有者が追加されます。もちろん、元の所有者が所有権を放棄した場合（たとえば、std :: shared_ptrを破棄できるようにすることで）、所有権の譲渡は完了です。

std :: moveを使用して所有権を譲渡する場合、何が起こっているかは明らかです。通常のコピーを使用する場合、元の所有者が所有権をすぐに放棄することを確認するまで、意図した操作が転送であることは明らかではありません。おまけとして、所有権のアトミックな移行により、所有者の数が1つ増加した（および参照カウントの付随する変更）一時的な状態を回避できるため、より効率的な実装が可能です。

少なくともlibstdc ++では、着信ポインターをoperator=呼び出すため、移動と割り当てで同じパフォーマンスが得られstd::moveます。参照：https : //github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/shared_ptr.h#L384