問題タブ [move-assignment-operator]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - make_unique の割り当てshared_ptr へ
私は(誤って)私のプログラムで次の課題を持っていました:
これを見つけたとき、なぜこれがコンパイルされるのか最初に疑問に思いました。には、オブジェクトshared_ptr
用の特別な移動代入演算子があることがわかりました。unique_ptr
私の質問は、これは常に安全に行うことができるのでしょうか、それとも何らかの意味がありますか?
(コードの実行に関しては安全です。コード レビューに関しては明らかに安全ではありません...)
c++ - 標準ライブラリの自己代入安全でない移動代入演算子の根拠は何ですか?
移動代入に関する標準ライブラリ ポリシーでは、自己代入が決して起こらないことを実装が想定できるようになっています。次のことを考えると、これは本当に悪い考えのように思えます。
- C++ の「通常の」(「コピー」) 割り当てコントラクトは、常に自己割り当てに対して安全であると見なされてきました。ここで、覚えて説明しなければならない C++ の一貫性のないコーナー ケースがさらに 1 つあります。また、微妙に危険なケースもあります。C++ に必要なのは、これ以上隠された罠ではないということは、私たち全員が同意していると思います。
- それはアルゴリズムを複雑にします -
remove_if
ファミリ内のすべてがこのコーナー ケースを処理する必要があります。 - この要件を満たすのは非常に簡単です-スワップを使用して移動を実装する場合は無料で提供され、他の場合(アドホックロジックでパフォーマンスを向上させることができる場合)でも、(ほとんど)一度も使用されませんブランチは、どの CPU¹ でも事実上無料です。また、最も興味深いケース (パラメーターまたはローカルを含む移動) では、インライン化時にオプティマイザーによってブランチが完全に削除されます (これは、「単純な」移動代入演算子の場合、ほぼ常に発生するはずです)。
では、なぜそのような決定を下すのでしょうか。
¹ 特にライブラリ コードでは、実装者が「ブランチの期待される結果」に関するコンパイラ固有のヒントを自由に利用できます ( VC++__builtin_expect
の gcc/で考えてください)。__assume