問題タブ [move-semantics]

私は2つのコンテナを持っています、それらが次のように定義されているとしましょう：

a両方を想定し、データbが入力されています。move-semanticsを使用して、コンテナ全体a をの特定の場所に挿入したいので、 sはに移動します。のどこかへの有効なイテレータであると仮定しましょう。以下は機能しません。bunique_ptrbib

この「移動による挿入範囲」を実現できる別のSTLアルゴリズムはありますか？ある種のが必要だと思いますがemplace_range、VS2010のSTLにはありません。挿入するたびにベクトルの内容全体がシフトアップするため、厄介なO（n ^ 2）になるため、1つずつ挿入するループを記述したくありません。他のオプションはありますか？

std::vector<T>外部リソース（またはなど）を使用した「値型」の問題はstd::string、それらのコピーは非常にコストがかかる傾向があり、コピーはさまざまなコンテキストで暗黙的に作成されるため、パフォーマンスの問題になる傾向があります。この問題に対するC++0xの答えは、移動セマンティクスです。これは、概念的にはリソースの盗用の概念に基づいており、技術的には右辺値参照によって強化されています。

Dには、移動セマンティクスまたは右辺値参照に似たものがありますか？

クラスのコピーを無効にするには、プライベートとして宣言する必要がありますが、定義はoperator=(const MyClass&)しMyClass(const MyClass&)ません。また、このクラスのmove ctorも無効にする必要がありますか？

push_backとの違いについて少し混乱していemplace_backます。

右辺値参照をとる過負荷があるpush_backので、目的がどうなるかよくわかりませんemplace_backか？

移動構築の目的で移動されたオブジェクトを、破棄のみ可能な状態のままにしておくことは合法/適切なc++ 0xですか? 例えば：

記録のために、割り当てられたメモリ領域を常に指しているはずのポインターメンバーを使用して、c++ クラスの ac 構造体をラップしようとしています。すべての C ライブラリ API は、この前提に依存しています。しかし、この要件は、移動後も x が有効なオブジェクトのままであるためには、独自の割り当てられたメモリ領域が必要になるため、真に安価な移動コンストラクタを作成することを妨げます。c API から対応するクリーンアップ関数を呼び出す前に、最初に NULL ポインターをチェックするようにデストラクタを作成しました。これにより、移動後に少なくとも構造体を安全に破棄できます。

「ムーブ セマンティクスを *this に拡張する」とは何かをわかりやすい英語で説明してもらえますか? 私はこの提案に言及しています。探しているのは、それが何であるか、なぜそれが必要なのかということだけです。ムーブセマンティクスが構築される右辺値参照が一般的に何であるかを理解していることに注意してください。そのような拡張が右辺値参照に何を追加するかを把握できません!

戻り値の最適化 (RVO と NRVO の両方) に関する今日のコンパイラの高品質を考慮すると、ムーブ コンストラクターとムーブ代入演算子の追加を開始することが実際にどのようなクラスの複雑さに意味があるのか​​疑問に思っていました。

たとえば、このreally_trivialクラスの場合、ムーブ セマンティクスは、RVO および NRVO がそのインスタンスをコピーするときに既に提供しているもの以上のものを提供できないと想定しています。

このsemi_complexクラスでは、ためらうことなくムーブ コンストラクターとムーブ代入演算子を追加します。

では、移動コンストラクターと移動代入演算子を追加することは、どのくらいの量で、どのような種類のメンバー変数で意味をなすのでしょうか?

次の C++0x 標準では、ムーブ コンストラクター内またはムーブ コンストラクター中に例外がスローされるとどうなりますか?

元のオブジェクトは残りますか? または、元のオブジェクトと移動先オブジェクトの両方が未定義の状態ですか? 言語によって提供される保証は何ですか?

私は単純なプログラマーです。私のクラスメンバー変数は、ほとんどの場合、PODタイプとSTLコンテナーで構成されています。このため、代入演算子やコピーコンストラクターを作成する必要はほとんどありません。これらはデフォルトで実装されているためです。

これに加えて、std::move移動できないオブジェクトで使用する場合は、代入演算子を使用します。つまりstd::move、完全に安全です。

this->member1_ = std::move(other.member1_);...私は単純なプログラマーなので、コンパイラーが単純に「 」として実装できるため、作成するすべてのクラスに移動コンストラクター/代入演算子を追加せずに、移動機能を利用したいと思います。

しかし、そうではありません（少なくともVisual 2010ではそうではありません）。これには特別な理由がありますか？

さらに重要なことには; これを回避する方法はありますか？

更新： GManNickGの答えを見下ろすと、彼はこのための優れたマクロを提供します。また、知らなかった場合は、move-semanticsを実装すると、スワップメンバー関数を削除できます。

私はそれに正しく入り、コードから始めると思います：

基本的に、私はオフストリームを返す必要があります。もちろん、ofstreamをコピーすることはできないので、クラステストのコードをいじって、上記をコンパイルして期待どおりに動作させました（gcc 4.5）。

しかし、これはコンパイラが「auto os = test（）」で「戻り値の最適化」（RTO）を実行しているためだと感じています。実際、次のように変更すると、次のようになります。

Test1とTest2の両方が出力に含まれなくなりました。

つまり、クラス「test」はコピーできないため、ofstreamが複製される可能性はありません。関数から返せるようにしたいだけです。そして、私はGCCでそれを行うことができるようです。

現在、これらのことを行わなくても機能するため、ストリームに割り当てられたヒープへのスマートポインターを逆参照したり、ファイルを再度開いたりしたくありません。私は自分のアプローチが少し「非標準的」であると感じているので、私が説明したことを行う標準的な方法は素晴らしいでしょう。