C++の文字列処理

コピーオンライト実装とは

string a = "hello!" ; string b = a ; // コピーコンストラクタ

は実際には の内容を にコピーしませんa。b代わりに、両方の文字列は内容を共有し、内容の参照カウントが増加します。実際のコピーは、文字の変更などの変更操作によって文字列の内容が変化するまで延期されます。

コピーオンライト戦略は、std::string有用な最適化であると見なされ、ほぼすべての実装で使用されたため、最初の C++ 標準で意図的に許可されました。^{[ 8 ]}しかし、間違いもありました。特に、operator[]C コード（など）を簡単に移植できるようにするために、非 const 参照を返すようにしたためs[5] = 'a'、コピーをトリガーする必要がありました。マルチスレッドにより、最適化（参照カウントが 1 の場合にコピーしないなど）が失敗しました^{[ 10 ]。}また、最新のプロセッサでは、参照カウントを調べたり変更したりするために必要なロックは、小さな文字列をコピーするよりもコストがかかります。^{[ 11 ]}

このため、実装は、最初はMSVC、後にGCCでコピーオンライトから離れることになった。^{[ 12 ]}この最適化は最終的にC++11で禁止された。^{[ 13 ]}

現在、ほとんどの実装では、16バイト（または23バイト）未満の文字列を文字列オブジェクトに格納し、バッファを割り当てないスモールストリング最適化（SSO）が採用されています。 ^{[ 14 ]}文字列の驚くほど多くの割合がこのように小さいため、これは参照カウントよりもはるかに高速です。また、バッファの割り当ては、ローカルメモリブロックのコピーに比べて非常にコストがかかります。

Javajava.lang.StringやC# などの他の言語とは異なりSystem.String、C++の文字列は常に可変です。引用符で囲まれたヌル終端文字列定数が、非可変クラスの目的のほとんどを果たしていたためです。C++では、次のコードで文字列のコピーを作成する必要があります。これは、コピーオンライト参照カウントを使用しても、ポインタを渡す場合と比べて非常に低速です。^{[ 11 ]}

import std ;std :: stringを使用します。void outputString ( string s ) { std :: print ( "{}" , s ); }// ... string s = "..." ; outputString ( s ); // s のコピーを作成しますoutputString ( "this is a literal string" ); // 文字列をコピーします（場合によっては2回コピーします）

コンパイラはインライン関数に対してこれを最適化できるが、これに依存するものは少なく、ほとんどの場合、文字列は定数参照として渡される。^{[ 15 ]}文字列定数からの変換には一時オブジェクトの構築も必要でstd::string、遅く、通常は関数のオーバーロードにつながる。

import std ;std :: stringを使用します。void outputString ( const string & s ) { std :: print ( "{}" , s ); }void outputString ( const char * s ) { std :: print ( "{}" , s ); }// ... string s = "..." ; outputString ( s ); // s をコピーせず、ポインタ/参照を渡しますoutputString ( "this is a literal string" ); // オーバーロードを呼び出し、生のポインタを渡します

C ++17標準では、読み取り専用データへのポインタと長さのみを持つstd::string_viewクラス^{[ 16 ]}が追加され、不変の一時std::stringオブジェクトの代替としてそのまま使用でき、値渡し引数を上記のどちらの例よりも高速化します。

import std ;using std :: string ; using std :: string_view ;void outputString ( string_view sv ) { std :: print ( "{}" , s ); }// ... string s = "..." ; outputString ( s ); // 間接参照のレベルが 1 つ減りますoutputString ( "これはリテラル文字列です" ); // さらに、コンパイラは strlen() を使用する必要性を最適化で取り除く可能性があります

C++17 では、文字列引数を取るライブラリ内のすべての関数を書き換えて、この利点を活用する必要があります。なぜなら、文字列から文字std::string_view列への変換はstd::string依然としてコストがかかるからです。

文字列ビューは、演算子を使用して文字列リテラルから構築できます。たとえば、^{[ 17 ]}std::literals::string_view_literals::operator""svstring_viewsv="Hello, world!"sv;

std::stringこれは、テンプレート クラスの特定のインスタンス化のためのtypedefです。^{[ 18 ]}その定義は<string>ヘッダーにあります。std::basic_string<CharT, Traits, Alloc>

namespace std { using string = basic_string < char > ; }

同様のクラス があり、これはwchar_tstd::wstringで構成され、WindowsではUTF-16テキストを、ほとんどのUnix ライクなプラットフォームではUTF-32テキストを格納するためによく使用されます。ただし、C++ 標準では、これらの型に対してUnicodeコード ポイントまたはコード ユニットとしての解釈を強制せず、が よりも多くのビットを保持することも保証していません。^{[ 19 ]}のプロパティに起因するいくつかの非互換性を解決するために、C++11では 2 つの新しいクラスと(新しい型とで構成され) が追加されました。これらは、すべてのプラットフォームでコード ユニットあたりのビット数が指定されています。^{[ 20 ]} C++11 では、16 ビットおよび 32 ビットの「文字」の新しい文字列リテラルと、Unicode コード ポイントを null 終端 (C スタイル) の文字列に入れるための構文も追加されました。^{[ 21 ]}wchar_tcharwchar_tstd::u16stringstd::u32stringchar16_tchar32_t

A は、それに付随する構造体std::basic_string<CharT, Traits, Alloc>を持つ任意の型に対して特殊化できることが保証されていますstd::char_traits<CharT>。C++11 の時点ではchar、、、wchar_tおよび特殊化char16_tのみchar32_tが実装される必要があります。^{[ 22 ]}ではstd::basic_string<CharT, Traits, Alloc>、2 つのテンプレート パラメータTraitsとには、デフォルトで、およびのAllocデフォルト値があります。std::char_traits<CharT>std::allocator<CharT>

Aは標準ライブラリのコンテナstd::basic_stringでもあるため、文字列内のコード単位に標準ライブラリのアルゴリズムを適用できます。

の設計は、 Herb Sutterstd::stringによってモノリシック設計の例として挙げられており、C++98 のクラスの 103 個のメンバ関数のうち 71 個は実装効率を損なうことなく分離できたはずだと推測している。 ^{[ 23 ]}