インターフェイスでstring_viewを使用する必要があるのはいつですか？

私は模倣Aに設計された内部ライブラリを使用しているC ++ライブラリを提案し、いつか過去数年間で、私はそのインターフェースが使用してから変更を参照std::stringしますstring_view。

そこで、新しいインターフェースに適合するようにコードを忠実に変更しました。残念ながら、私が渡さなければならないのは、std :: stringパラメーターと、std :: string戻り値です。そのため、私のコードは次のように変更されました。

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   api.setup (p1, special_number_to_string(p2));
}

に

void one_time_setup(const std::string & p1, int p2) {
   api_class api;
   const std::string p2_storage(special_number_to_string(p2));
   api.setup (string_view(&p1[0], p1.size()), string_view(&p2_storage[0], p2_storage.size()));
}

私は、この変更がAPIクライアントとして私に何を買ったのか、実際には、コードを増やすこと以外は見当たらないでしょう（おそらく失敗するためです）。API呼び出しの安全性は低下し（APIがパラメーターのストレージを所有しなくなったため）、おそらくプログラム0の作業を節約しました（コンパイラーができる最適化の移動により）。起動後またはどこかで大きなループで行われない、または行われない割り当てがいくつかあります。このAPI用ではありません。

ただし、このアプローチは、他の場所で見られるアドバイス、たとえば次の回答に従うようです。

余談ですが、C ++ 17以降では、std :: string_viewを優先してconst std :: string＆を渡すことは避けてください。

主に最適化の目的で、比較的安全なオブジェクトを安全性の低いオブジェクト（基本的には栄光のポインタと長さ）に普遍的に置き換えることを提唱しているように見えるため、このアドバイスは驚くべきものです。

だから、ときなければならない string_view使用すること、そしてときにそれをべきではないのですか？

1. 値を取る機能は文字列の所有権を取得する必要がありますか？その場合は、std::string（非定数、非参照）を使用します。このオプションを使用すると、呼び出し側のコンテキストで再び使用されないことがわかっている場合、値を明示的に移動することもできます。
2. 機能は文字列を読み取るだけですか？使用もしそうならstd::string_view（定数、非参照）ので、これはstring_view扱うことができるstd::stringとchar*簡単に問題なく、コピーをせずに。これにより、すべてのconst std::string&パラメーターが置き換えられます。

最終的には、あなたのようにコンストラクタを呼び出す必要はないはずstd::string_viewです。変換を自動的に処理std::stringする変換演算子があります。

A std::string_viewはconst char*C ++ にaの利点のいくつかをもたらしますstd::string。string_view とは異なり

• メモリーを所有していない、
• メモリを割り当てません。
• あるオフセットで既存の文字列を指すことができます。
• ポインタ間接参照のレベルは、aより1つ少ないstd::string&。

つまり、string_viewは、生のポインターを処理することなく、コピーを避けることができます。

最新のコードでstd::string_viewは、const std::string&関数パラメーターのほぼすべての使用を置き換える必要があります。std::string変換演算子をに宣言しているため、これはソース互換の変更である必要がありますstd::string_view。

とにかく文字列を作成する必要がある特定のユースケースでは文字列ビューが役に立たないからといって、それが一般的に悪い考えであることを意味するわけではありません。C ++標準ライブラリは、利便性よりも一般性のために最適化される傾向があります。文字列ビューを自分で作成する必要はないため、「安全性が低い」引数は保持されません。

主に最適化の目的で、比較的安全なオブジェクトを安全性の低いオブジェクト（基本的には栄光のポインタと長さ）に普遍的に置き換えることを提唱しているように見えるため、このアドバイスは驚くべきものです。

これはこの目的を少し誤解していると思います。これは「最適化」ですが、実際にはを使用しなくても済むようにする必要がありますstd::string。

C ++のユーザーは、多数の異なる文字列クラスを作成しました。固定長文字列クラス、バッファサイズがテンプレートパラメータであるSSO最適化クラス、それらの比較に使用されるハッシュ値を格納する文字列クラスなど。COWベースの文字列を使用する人もいます。C ++プログラマがやりたいことが1つある場合は、文字列クラスを作成します。

また、Cライブラリが作成および所有する文字列は無視されます。char*おそらく、何らかのサイズの裸のs。

したがって、ライブラリを作成していて、を取得するconst std::string&場合、ユーザーは使用している文字列をすべて取得し、にコピーする必要がありstd::stringます。たぶん何十回も。

std::stringの文字列固有のインターフェイスにアクセスする場合、なぜ文字列をコピーする必要があるのですか？それはとても無駄です。

string_viewパラメータとして使用しない主な理由は次のとおりです。

1. 最終的な目標が、文字列をNULで終了する文字列（fopenなど）を受け取るインターフェイスに渡すことである場合。std::stringNUL終了が保証されています。string_viewそうではありません。また、ビューをサブストリング化して、NULで終了しないようにすることは非常に簡単です。サブストリングa std::stringは、サブストリングをNUL終了範囲にコピーします。

   まさにこのシナリオのために、特別なNULで終了するstring_viewスタイルタイプを作成しました。ほとんどの操作を実行できますが、NUL終了ステータスを壊す操作はできません（たとえば、最後からトリミングする）。

2. 生涯の問題。本当にstd::stringそれをコピーする必要がある場合、または文字列を関数呼び出しよりも長くする必要がある場合は、const std::string &。または、単なるstd::string値パラメーターとして。そうすれば、そのような文字列が既にある場合、すぐに所有権を主張でき、呼び出し元は文字列のコピーを保持する必要がない場合、文字列に移動できます。