C ++ 11でのCOW std :: string実装の合法性

コピーオンライトはstd::stringC ++ 11での適合を実装するための実行可能な方法ではないというのが私の理解でしたが、最近議論されたとき、私は自分がそのステートメントを直接サポートできないことに気付きました。

C ++ 11がCOWベースの実装を許可しないことは正しいstd::stringですか？

もしそうなら、この制限は新しい標準のどこかに（どこで）明示的に述べられていますか？

または、この制限は、std::stringCOWベースのの実装を妨げる新しい要件の複合効果であるという意味で、暗黙のうちに含まれていstd::stringますか。この場合、「C ++ 11はCOWベースのstd::string実装を効果的に禁止する」という章と詩のスタイルの派生に興味があります。

標準21.4.1 p6に従い、イテレータ/参照の無効化は、

—引数として非const basic_stringへの参照を使用する標準ライブラリ関数の引数として。

— operator []、at、front、back、begin、rbegin、end、およびrendを除く、非constメンバー関数の呼び出し。

COW文字列の場合、non-const operator[]を呼び出すにはコピーを作成する必要があり（参照を無効にする）、これは上記の段落では許可されていません。したがって、C ++ 11でCOW文字列を使用することはもはや合法ではありません。

Dave Sと gbjbaanbの答えは正しいです。（そしてLuc Dantonも正しいですが、COW文字列を禁止するのは、元のルールではなく、それを禁止することによる副作用です。）

しかし、混乱を解消するために、さらに説明を追加します。さまざまなコメントが、次の例を示すGCCバグジラに関する私のコメントにリンクしています。

std::string s("str");
const char* p = s.data();
{
    std::string s2(s);
    (void) s[0];
}
std::cout << *p << '\n';  // p is dangling

その例の要点は、GCCの参照カウント（COW）文字列がC ++ 11では無効である理由を示すことです。C ++ 11標準では、このコードが正しく機能する必要があります。pC ++ 11では、コードの何も無効にできません。

GCCの古い参照カウントstd::string実装を使用すると、そのコードp は無効化され、ぶら下がりポインタになるため、未定義の動作になります。（何が起こるかというとときということでs2構築され、それはでデータを共有するsが、非const参照を取得することを経由してs[0]共有を解除するためにデータを必要とするので、s参照があるため、「コピーオンライト」を行いs[0]、潜在的に書き込みに使用することができs、その後、s2行きますスコープ外で、p）が指す配列を破棄します。

C ++ 03標準は、21.3 [lib.basic.string] p5でその動作を明示的に許可してdata()おり、最初の呼び出しの呼び出しの後に、operator[]()ポインター、参照、および反復子が無効になる可能性があると述べています。したがって、GCCのCOW文字列は有効なC ++ 03実装でした。

C ++ 11標準では、この動作を許可していません。これoperator[]()は、への呼び出しの後に続くかどうかに関係なく、への呼び出しによってポインター、参照、または反復子が無効になることはないためdata()です。

上記の例だから、必見の C ++ 11での作業が、ないと仕事にlibstdc ++の種類COW文字列の、COW文字列の種類は、11 C ++で許可されていないため、という。

それは、CoWはより高速な文字列を作成するための許容可能なメカニズムです...しかし...

マルチスレッドコードが遅くなります（多くの文字列を使用している場合、1つだけの書き込みかどうかを確認するためのロックにより、パフォーマンスが低下します）。これが、CoWが数年前に殺された主な理由でした。

他の理由は、[]オペレーターが文字列データを返すことです。他の誰かが変更しないと期待している文字列を上書きする保護はありません。同じことが、にも適用されるc_str()とdata()。

クイックグーグルによると、マルチスレッドは基本的に（明示的にではなく）事実上許可されなかった理由です。

提案は言う：

提案

すべてのイテレータと要素のアクセス操作を安全に同時に実行できるようにすることを提案します。

シーケンシャルコードでも操作の安定性を高めています。

この変更により、コピーオンライトの実装が事実上禁止されます。

に続く

コピーオンライト実装からの切り替えによるパフォーマンスの最大の潜在的な損失は、非常に大きな読み取りが主な文字列を持つアプリケーションのメモリ消費の増加です。ただし、これらのアプリケーションではロープの方が優れた技術的ソリューションであると考えており、ライブラリTR2に含めるためにロープの提案を検討することをお勧めします。

ロープはSTLPortおよびSGIs STLの一部です。

21.4.2からbasic_stringコンストラクタと代入演算子[string.cons]

basic_string(const basic_string<charT,traits,Allocator>& str);

[...]

2 効果：basic_string表64に示すように、クラスのオブジェクトを作成します。[...]

表64は、この（コピー）コンストラクターを介してオブジェクトを構築した後this->data()、次の値を持っていることを示しています。

str.data（）が最初の要素を指す配列の割り当てられたコピーの最初の要素を指します

他の同様のコンストラクターにも同様の要件があります。

文字列が連続して格納されていることが保証され、文字列の内部ストレージへのポインタを取得できるようになりました（つまり、＆str [0]は配列の場合と同じように機能します）、有用なCOWを作成することはできません。実装。あなたはあまりにも多くのもののためにコピーを作成する必要があります。だけでも、使用operator[]またはbegin()非const文字列にコピーが必要になります。

basic_stringC ++ 11以降ではCOWは禁止されていますか？

について

」アム私はC ++ 11がのCOWベースの実装を認めていないことを修正しますかstd::string？

はい。

について

」もしそうなら、この制限は、明示的に（どこ）新規格のどこかに記載されていますか？

ほとんど直接的に、COW実装で文字列データのO（ n）物理コピーを必要とする多くの操作の一定の複雑さの要件による。

たとえば、メンバー関数の場合

auto operator[](size_type pos) const -> const_reference;
auto operator[](size_type pos) -> reference;

…COW実装では、どちらも文字列データのコピーをトリガーして文字列値の共有を解除しますが、C ++ 11標準では

” 複雑さ：一定の時間。

…このようなデータのコピー、つまりCOWを除外します。

C ++ 03によるCOW実装をサポートしていないの呼び出しできるように、これらの一定の複雑さの要件を有し、一定の制約条件の下で、でoperator[]()、at()、begin()、rbegin()、end()、またはrend()文字列の項目を参照無効の参照、ポインタとイテレータに、つまりはおそらく被るAにCOWデータのコピー。このサポートはC ++ 11で削除されました。

COWもC ++ 11無効化ルールによって禁止されていますか？

執筆時にソリューションとして選択された別の回答では、非常に賛成されているため、明らかに信じられており、

」 COW列について、呼び出し非はconst operator[][C ++ 11§21.4.1/ 6]上記[引用]段落によって禁止され、コピーを作成（及び参照を無効化）が必要となります。したがって、C ++ 11でCOW文字列を使用することはもはや合法ではありません。

その主張は不正確であり、主に2つの点で誤解を招きます。

• これは、非constアイテムアクセサーのみがCOWデータのコピーをトリガーする必要があることを誤って示しています。
  ただし、constアイテムアクセサーはデータコピーをトリガーする必要があります。これにより、クライアントコードが参照またはポインターを形成できるようになるため（C ++ 11では）、COWデータコピーをトリガーできる操作を介して後で無効にすることはできません。
• COWデータのコピーによって参照が無効になる可能性があると誤って想定しています。
  ただし、正しい実装では、COWデータのコピー、文字列値の共有解除は、無効化できる参照がある前の時点で行われます。

の正しいC ++ 11 COW実装がどのように機能するかを確認するbasic_stringために、これを無効にするO（1）要件が無視される場合、文字列が所有権ポリシーを切り替えることができる実装を考えてください。文字列インスタンスは、ポリシーSharableで始まります。このポリシーがアクティブな場合、外部アイテム参照はありません。インスタンスは一意のポリシーに移行でき、.c_str()（少なくとも内部バッファーへのポインターを生成する場合）への呼び出しなどでアイテム参照が作成される可能性がある場合は、移行する必要があります。値の所有権を共有する複数のインスタンスの一般的なケースでは、これは文字列データのコピーを伴います。一意のポリシーへの移行後、インスタンスは、割り当てなどのすべての参照を無効にする操作によってのみ、共有可能に戻ることができます。

したがって、COW文字列が除外されているという回答の結論は正しいものの、提示された推論は正しくなく、誤解を招く可能性があります。

この誤解の原因は、C ++ 11の附属書Cの非規範的な注記であると思います。

変更：basic_string要件は参照カウント文字列を許可しなくなりました
根拠：参照カウント文字列との無効化は微妙に異なります。この変更により、この国際規格の動作（sic）が正規化されます。
元の機能への影響：この国際標準では、有効なC ++ 2003コードの実行が異なる場合があります

ここで、理論的根拠は、C ++ 03の特別なCOWサポートを削除することにした主な理由を説明しています。この理由、その理由は、標準がCOWの実装を効果的に禁止する方法ではありません。標準では、O（1）要件によるCOWは許可されていません。

要するに、C ++ 11無効化ルールはのCOW実装を除外しませんstd::basic_string。しかし、それらは、g ++の標準ライブラリ実装の少なくとも1つにあるような、合理的に効率的な無制限のC ++ 03スタイルのCOW実装を除外します。特別なC ++ 03 COWサポートによりconst、無効化のための微妙で複雑なルールを犠牲にして、特にアイテムアクセサーを使用して実用的な効率を実現しました。

」参照、ポインタ、の要素を参照する反復子basic_string配列は、以下の使用によって無効にすることができるbasic_stringオブジェクト：
-非メンバ関数への引数としてswap()（21.3.7.8）、operator>>()（21.3.7.9）、及びgetline()（21.3。 7.9）。
—の引数としてbasic_string::swap()。
—呼び出しdata()およびc_str()メンバー関数。
-非呼び出しconstを除いて、メンバ関数をoperator[]()、at()、begin()、rbegin()、end()、とrend()。
-の形以外は、上記の用途のいずれかに続いinsert()及びerase()非最初の呼び出し、戻りイテレータconstメンバ関数operator[]()、at()、begin()、rbegin()、end()、またはrend()。

これらのルールは非常に複雑で微妙なので、多くのプログラマがいたとしても、正確な要約を提供できるとは思えません。私ができなかった。

O（1）要件が無視されるとどうなりますか？

たとえばC ++ 11の一定の時間要件operator[]が無視される場合、COW for basic_stringは技術的には実現可能ですが、実装するのは困難です。

COWデータのコピーを行わずに文字列の内容にアクセスできる操作には、次のものがあります。

• による連結+。
• を介して出力し<<ます。
• basic_string標準ライブラリ関数への引数としての使用。

後者は、標準ライブラリが実装固有の知識と構造に依存することが許可されているためです。

さらに、実装では、COWデータのコピーをトリガーせずに文字列コンテンツにアクセスするためのさまざまな非標準関数を提供できます。

主な複雑な要因は、C ++ 11では、basic_stringアイテムへのアクセスがデータのコピー（文字列データの非共有化）をトリガーする必要があるが、スローしないようにする必要があることです。たとえば、C ++ 11§21.4.5/ 3「スロー：なし」。そのため、通常の動的割り当てを使用してCOWデータをコピーするための新しいバッファーを作成することはできません。これを回避する1つの方法は、実際に割り当てることなくメモリを予約できる特別なヒープを使用して、文字列値への各論理参照に必要な量を予約することです。そのようなヒープでの予約と予約解除は一定の時間O（1）であり、すでに予約されている量を割り当てることは、noexcept。標準の要件に準拠するために、このアプローチでは、個別のアロケーターごとにそのような特別な予約ベースのヒープが1つ必要になると思われます。

^{注：
¹ constアイテムアクセサーは、クライアントコードがデータへの参照またはポインターを取得できるため、COWデータコピーをトリガーします。これは、非constアイテムアクセサーなどによってトリガーされた後のデータコピーによって無効にすることが許可されていません。}

私は常に不変の牛について疑問に思っていました。牛が作成されると、別の牛からの割り当てによってのみ変更できるため、標準に準拠することになります。

簡単な比較テストのために今日試してみる時間がありました：文字列/牛によってキーが付けられたサイズNのマップで、すべてのノードがマップ内のすべての文字列のセットを保持しています（オブジェクトの数はNxNです）。

文字列のサイズが300バイト以下で、N = 2000の牛の方がわずかに高速で、使用するメモリがほぼ1桁少なくなります。以下を参照してください。サイズはキロバイト単位、ランbは牛の場合です。

~/icow$ ./tst 2000
preparation a
run
done a: time-delta=6 mem-delta=1563276
preparation b
run
done a: time-delta=3 mem-delta=186384