`const std::string&` による `std::string` の受け渡しは最新の C においても有益ですか?

パラメータとして Const std::string & を渡すことにはもう利点がありますか?

最近の講演で、著名な C 専門家 Herb Sutter 氏が次のように述べています。 const & によって std::vector と std::string を渡すための引数はもはや強制的ではありません。これを説明するために、彼は次のように記述する関数を提案しました。

std::string do_something ( std::string inval )
{
   std::string return_val;
   // ... do stuff ...
   return return_val;
}

ハーブは、return_val は関数が返される時点で右辺値になるため、コスト効率の高い移動セマンティクスを使用して返すことができると推論しました。ただし、疑問は残ります。なぜ入力パラメータ inval を参照渡しするのでしょうか? std::string オブジェクトのサイズが大きくなると (ヒープ ポインターや char 配列などのコンポーネントのせいで)、値渡しの方が有利になりませんか?

Herb の理論的根拠

Herb の提案は、複数の入れ子関数が関係するシナリオに基づいています。関数 A が関数 B を呼び出し、関数 B が関数 C を呼び出し、それぞれ文字列パラメータを渡す状況を考えてみましょう。 B と C が文字列を const & として受け取る場合、コードは次のようになります。

void B(const std::string & str) {
  C(str);
}

void C(const std::string & str) {
  // Use `str` without storing it.
}

このアプローチでは、コピーや移動を避けて効率的にポインターを渡します。 C は文字列を格納しないため、const & を受け取ります。

ただし、C が文字列を格納する必要があるとします。 C を次のように変更すると、B はパラメータへのコピーを実行することになり、利点がなくなります。

void C(const std::string & str) {
  // ...
  m_str = str;
}

対照的に、str がすべての関数を通じて値によって渡された場合、std::move to に依存します。データの移動を処理する場合、C は単に一時文字列の所有権を受け入れるだけで、コピーの必要がなくなります。

コスト考慮事項

値渡しでは、参照を使用する場合と比べてパフォーマンスが若干低下しますが、SSO で小さな文字列をコピーするコストに匹敵する可能性があります。これらのアプローチのどちらを選択するかは、メモリ割り当ての頻度と特定の使用例によって異なります。

以上が`const std::string&` による `std::string` の受け渡しは最新の C においても有益ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。