shared_ptrを参照または値のどちらで渡す必要がありますか？

関数がshared_ptr（boostまたはC ++ 11 STLから）取るとき、それを渡しますか？

• const参照： void foo(const shared_ptr<T>& p)

• または値によって： void foo(shared_ptr<T> p)？

最初の方法の方が速いのではないかと思います。しかし、これは本当に価値があるのですか、それとも他に問題がありますか？

あなたが選択した理由を教えてください、または場合は、それが問題ではないと思う理由。

この質問は、C ++ and Beyond 2011のAsk Us AnythingセッションでScott、Andrei、Herbによって議論され、回答されています。パフォーマンスと正確さについては4:34からご覧ください。shared_ptr

簡単に言うと、目的がオブジェクトの所有権を共有することでない場合（たとえば、異なるデータ構造間、または異なるスレッド間）、値で渡す理由はありません。

上記のリンクされたトークビデオでScott Meyersによって説明されているように移動最適化できなければ、それは使用できるC ++の実際のバージョンに関連しています。

GoingNative 2012カンファレンスのインタラクティブパネルで、このディスカッションが大幅に更新されました。これは、特に22:50から見る価値があります。

ここだハーブサッターのテイク

ガイドライン：所有権の共有や譲渡など、スマートポインター自体を使用または操作する場合を除き、スマートポインターを関数パラメーターとして渡さないでください。

ガイドライン：関数が値によるshared_ptrパラメーターを使用してヒープオブジェクトの所有権を格納および共有することを示します。

ガイドライン：非const shared_ptr＆パラメーターは、shared_ptrを変更する場合にのみ使用してください。コピーを取得して所有権を共有するかどうかわからない場合のみ、パラメーターとしてconst shared_ptr＆を使用します。それ以外の場合は、代わりにwidget *（またはnull可能でない場合はwidget＆）を使用します。

個人的にはconstリファレンスを使用します。関数呼び出しのために参照カウントを再びデクリメントするためだけに参照カウントをインクリメントする必要はありません。

const参照渡し、より高速です。それを格納する必要がある場合は、たとえば、あるコンテナに入れてください。countは、コピー操作によって自動的にインクリメントされます。

私は一度で、以下のコードを実行した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;
}

Intel Core 2 Quad（2.4GHz）プロセッサーでVS2015、x86リリースビルドを使用

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

値によるコピーのバージョンは、桁違いに遅いものでした。
現在のスレッドから同期的に関数を呼び出す場合は、const&バージョンを優先します。

C ++ 11以降では、あなたが考えているよりも頻繁にconst＆よりも値でそれをとるべきです。

std :: shared_ptr（基礎となる型Tではなく）を使用している場合は、それを使用して何かを実行したいため、そうしています。

コピーしたい場合どこか、const＆で取得して後でコピーするのではなく、コピーで取得してstd :: moveを内部で移動する方が理にかなっています。これは、関数を呼び出すときに呼び出し側にstd :: move shared_ptrを順に移動するオプションを許可し、インクリメントおよびデクリメント操作のセットを節約できるためです。か否か。つまり、関数の呼び出し元は、関数の呼び出し後にstd :: shared_ptrが必要かどうか、および移動するかどうかに応じて決定できます。これは、const＆で渡す場合は達成できません。そのため、値で取得することをお勧めします。

もちろん、呼び出し元の両方が長い間shared_ptrを必要とし（したがって、std :: moveできない）、関数内にプレーンコピーを作成したくない場合（弱いポインターが必要な場合、または場合によっては必要な場合のみ）いくつかの条件に応じてそれをコピーするには）、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);

この場合、常に内部でコピーを作成するため

atomic_incrementとdecrementが存在するshared_copyコピー操作の時間コストがわからないため、CPU使用率の問題が非常に大きくなりました。アトミックなインクリメントとデクリメントにはそれほどのコストがかかるとは思いませんでした。

私のテスト結果によると、int32アトミックインクリメントおよびデクリメントは、非アトミックインクリメントおよびデクリメントよりも2または40倍かかります。私はWindows 8.1の3GHz Core i7でそれを手に入れました。前者は競合が発生しない場合、後者は競合の可能性が高い場合です。アトミック操作がハードウェアベースのロックであることに注意してください。ロックはロックです。競合が発生するとパフォーマンスが低下します。

これを経験して、私は常にbyval（shared_ptr）よりもbyref（const 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は十分な大きさではありません。また、参照による受け渡しとコピーによる受け渡しのパフォーマンスを考慮に入れるために、コピーから十分なオーバーヘッドを確保するために、そのコンストラクタ\デストラクタが十分な作業を行いません。