Qt ウィジェットは暗黙的な共有を使用することが知られています。std::vector
したがって、 stl コンテナ、std::string
暗黙の共有も使用する場合に興味があります。
いいえの場合、なぜですか? とても便利なので。
答えが「はい」の場合、どうすればそれを確認できるでしょうか? stl コンテナーが暗黙的な共有を使用していることを示す単純な C++ stl プログラムが必要です。コピー時にディープコピーを行いません。
いいえ、できません。コンテナーの内容を変更しようとしたり、コンテナーでミュータブルbegin()
を呼び出したりすると、コピーオンライトの可能性があり、コンテナーへのすべての参照とイテレーターが無効になります。これはデバッグが難しい状況であり、禁止されています。
技術的std::string
にはコンテナではありませんが、C ++ 11以降、コピーオンライトを実行することは引き続き禁止されています。
basic_stringシーケンスの要素を参照する参照、ポインター、およびイテレーターは、そのbasic_stringオブジェクトを次のように使用することで無効になる可能性があります。...—
operator
[ ]、at、front、back、begin、 rbegin、end、およびrend。
[string.require]
...とても便利なので。
え、何のために?参照による受け渡しは、ほとんどの場合、すべての「パフォーマンスの問題」を解決します。Atomic ref-countsは、マルチプロセッサマシンでは本質的にスケーラブルではありません。
コンテナ内での CoW の動作に対して他の人が提起した反対意見は別として、いくつかの反対意見を以下に示します。これらはすべて、慣例に反する動作のカテゴリに分類されるため、無防備な開発者に奇妙なバグを引き起こす可能性があります。
例外
CoW を許可すると、コンテナに対する無害なミューテーション操作が例外で失敗する可能性があることを意味します。これはoperator[]
、std::vector
またはstd::string
ねじ切り
その後の並行性について心配することなく、別のスレッドに渡すという明確な目的でコンテナをコピー構築できると合理的に期待するかもしれません。CoWではそうではありません。
同様の質問で気づいたように:
C++ 標準では、コピー オン ライトやその他の実装の詳細を禁止または義務付けていません
std::string
。セマンティクスと複雑さの要件が満たされている限り、実装は好きな実装戦略を選択できます。
同じことが当てはまると思いますstd::vector
また、このトピックに興味があるかもしれません: std::string の実装方法