コピーオンライトセマンティクスのメリット

コピーオンライトにはどのようなメリットがあるのでしょうか。当然、私は個人的な意見を期待していませんが、それが技術的かつ実用的に有益な方法で具体的な方法で実際に利用できる実際のシナリオです。そして、具体的には、&文字の入力を節約する以上のものを意味します。

明確にするために、この質問はデータ型のコンテキストにあります。割り当てまたはコピーの構築は暗黙的な浅いコピーを作成しますが、変更すると暗黙的なディープコピーが作成され、元のオブジェクトではなく変更が適用されます。

私が尋ねている理由は、COWをデフォルトの暗黙の動作として使用することのメリットを見つけられないようです。多くのデータ型に対してCOWが実装されているQtを使用します。実際にはすべて、動的に割り当てられたストレージがいくつかあります。しかし、それは実際にユーザーにどのようなメリットがありますか？

例：

QString s("some text");
QString s1 = s; // now both s and s1 internally use the same resource

qDebug() << s1; // const operation, nothing changes
s1[o] = z; // s1 "detaches" from s, allocates new storage and modifies first character
           // s is still "some text"

この例でCOWを使用することで何が得られるでしょうか。

私たちがやろうとしているのがconst操作のs1使用だけである場合、冗長であり、を使用することもできますs。

値を変更する場合、COWは最初の非const操作までリソースコピーを遅らせるだけですが、暗黙的共有の参照カウントをインクリメントして共有ストレージから切り離すという（最小限ではありますが）コストがかかります。COWに伴うすべてのオーバーヘッドは無意味であるように見えます。

パラメータの受け渡しのコンテキストはそれほど変わらない-値を変更するつもりがない場合は、const参照として渡し、変更したい場合は、変更したくない場合は暗黙のディープコピーを作成する元のオブジェクト、または変更する場合は参照渡し。繰り返しになりますが、COWは不要なオーバーヘッドのように見え、何も実行されず、変更が元のオブジェクトから切り離されるため、必要な場合でも元の値を変更できないという制限が追加されるだけです。

したがって、COWについて知っているか、それとも知らないかに応じて、コードの目的が不明瞭になり、不要なオーバーヘッドが発生したり、予期しない動作を完全に混乱させたりして、頭を悩ませる可能性があります。

私には、不要なディープコピーを避けたい場合でも、作成するつもりでも、より効率的で読みやすいソリューションがあるようです。では、COWの実際的なメリットはどこにあるのでしょうか。このような人気のある強力なフレームワークで使用されているため、いくつかの利点があるに違いないと思います。

さらに、私が読んだことから、COWはC ++標準ライブラリでは明示的に禁止されています。私がそれに見ている詐欺がそれと何か関係があるかどうかはわかりませんが、いずれにせよ、これには理由があるはずです。

コピーオンライトは、オブジェクトのコピーを作成し、変更しないことが非常に多い場合に使用されます。それらの状況では、それはそれ自体で元が取れます。

あなたが述べたように、あなたはconstオブジェクトを渡すことができ、多くの場合それで十分です。ただし、constは、呼び出し元がそれを変更できないことを保証するだけです（const_castもちろん、それらを変更しない限り）。マルチスレッドの場合や、コールバック（元のオブジェクトを変更する可能性がある）がある場合は処理しません。COWオブジェクトを値で渡すと、APIユーザーではなくAPI開発者にこれらの詳細を管理するという課題が生じます。

C + 11の新しい規則ではstd::string、特にCOWを禁止しています。文字列のイテレータは、バッキングバッファが切り離されている場合は無効にする必要があります。イテレータがchar*（string*とインデックスではなく）として実装されていた場合、このイテレータは無効になります。C ++コミュニティは、反復子が無効にされる頻度を決定するoperator[]必要があり、その決定はそれらのケースの1つであってはならないということでした。 operator[]でがstd::string返さchar&れます。これは変更される場合があります。したがって、operator[]文字列を切り離してイテレータを無効にする必要があります。これは、貧しい貿易とみなす、などの機能とは違ったend()とcend()、ののconstバージョンを依頼する方法はありませんoperator[]文字列をキャストのconstの短いです。（関連）。

COWはまだ生きており、STLの外でも十分です。特に、非常に軽量なオブジェクトのように見えるものの背後にある重いオブジェクトがあることをAPIのユーザーが期待することが不合理である場合に、それが非常に役立つことがわかりました。COWをバックグラウンドで使用して、そのような実装の詳細に関係する必要がないようにすることができます。

文字列などの場合、文字列の一般的なケースは小さい文字列であることが多く、COWのオーバーヘッドが小さい文字列を単にコピーするコストをはるかに上回る傾向があるため、そうでない場合よりも一般的なユースケースを悲観的にするようです。小さなバッファの最適化は、文字列のコピーの代わりに、そのような場合のヒープ割り当てを回避するために私にとってはるかに意味があります。

ただし、Androidのようなより重いオブジェクトがあり、それをコピーしてそのサイバネティックアームを置き換えるだけの場合、COWは変更可能な構文を維持しながら、Android全体をディープコピーする必要をなくすための方法として非常に合理的です。コピーにユニークな腕を与えます。その時点で永続的なデータ構造として不変にすることは優れているかもしれませんが、個々のAndroidパーツに適用される「部分的なCOW」は、これらの場合には妥当なようです。

そのような場合、Androidの2つのコピーは、同じ胴体、脚、足、頭、首、肩、骨盤などを共有/インスタンス化します。それらの間で異なり、共有されない唯一のデータは、作成された腕です。その腕を上書きする2番目のアンドロイドのためにユニークです。