問題タブ [rvalue-reference]

以下のコードでは：

MakePair を実行しようとすると、奇妙な理由でエラーが発生します。なぜですか? 神のみぞ知る...

これは次のエラーです:
エラー エラー C2665: Pair::Pair' : none of the 3 overloads could convert the all argument types

どの変換を実行する必要があるのか​​ わかりませんか？

コンストラクターに最適な形式を考えています。サンプルコードは次のとおりです。

私が理解していることから、これはコンパイラーがそれぞれの状況で実行できる最善の方法です。

（1a）yはx1.m_yにコピーされます（1コピー）

（1b）yはXのコンストラクターの引数にコピーされ、次にx1.m_yにコピーされます（2コピー）

（1c）yはx1.m_yに移動されます（1移動）

（2a）f（）の結果がx2.m_yにコピーされます（1コピー）

（2b）f（）はコンストラクターの引数に組み込まれ、x2.m_yにコピーされます（1コピー）

（2c）f（）がスタック上に作成され、x2.m_yに移動されます（1移動）

ここでいくつかの質問：

1. どちらの場合も、const参照による受け渡しは悪くはなく、値による受け渡しよりも優れている場合があります。これは、 「スピードが欲しいですか？値渡し」に関する議論に反しているようです。。C ++（C ++ 0xではない）の場合、これらのコンストラクターのconst参照による受け渡しを使用する必要がありますか、それとも値による受け渡しを行う必要がありますか？また、C ++ 0xの場合、値渡しよりも右辺値参照を渡す必要がありますか？

2. （2）の場合、一時的なものがx.m_yに直接構築されているとよいでしょう。右辺値バージョンでさえ、オブジェクトが動的メモリを割り当てない限り、コピーと同じくらいの作業である移動が必要だと思います。コンパイラがこれらのコピーや移動を回避できるようにこれをコーディングする方法はありますか？

3. 私は、コンパイラーが最善を尽くすことができると思うことと、私の質問自体の両方で多くの仮定をしました。正しくない場合は、これらのいずれかを修正してください。

なぜこれがコンパイルされ、なぜttype で終わるのか、誰でも説明できますint&か?

これは GCC 4.5.0 20100604 および GDB 7.2-60.2 で見られます

右辺値参照を使用して gcc で正常に動作する引数を格納するコールバック実装がありますが、一部のコードでは VS 2010 でコンパイルできません。短いバージョン:

gcc 4.4 では、以下が生成されます。

$ g++ clbck.cpp -std=c++0x -o clbck && ./clbck
関数 sample1 はこちら
関数 sample2 はこちら
関数 sample2 はこちら

ただし、マークされた行のために registerFunc をインスタンス化しようとすると、VS 2010 でコンパイルに失敗します。

エラー C2664: 'F::F(FuncType,ArgType &&)' : パラメータ 2 を 'const char *' から 'const char *&&' に変換できません
[
FuncType
=void (__cdecl *)(std::string),
ArgType =const char *
]
左辺値を右辺値参照にバインドすることはできません

Googling は VS2010 の Boost 1.44 で同様のエラーを発見しましたが、推奨される解決策は右辺値参照をまったく使用しないことです。本当に他に方法はないのでしょうか?

そして、あなたがそれに取り組んでいる間、これらのコールバックを処理している方法に何か問題がありますか? 関数ポインターとファンクター (私はまだラムダをテストしていません) で問題なく動作します。私が見つけた唯一の欠点は、上記のものです。(ここに示されているコードは単なるデモであり、実際のコードではユーザーにポインターを提供していないことに注意してください。実際にこれを使用して、Qt アプリケーションのさまざまなスレッドで関数を実行しています)。

C++03 でプログラミングする場合、名前のない一時変数T()を function に渡すことはできませんvoid foo(T&);。通常の解決策は、一時的に名前を付けてから、次のように渡すことです。

さて、C++0x が登場しました。右辺値参照を使用すると、次のように定義された関数void foo(T&&)を使用して、一時的なものを渡すことができます。右辺値参照を取る関数は、右辺値参照 (名前のない一時参照) と左辺値参照 (名前付きの非 const 参照) の両方を取ることができるため、関数パラメーターで左辺値参照を使用する理由はありますか? 関数のパラメーターとして常に右辺値を使用するべきではありませんか?

確かに、左辺値参照を受け取る関数は、呼び出し元が一時値を渡すのを防ぎますが、それが有用な制限であるかどうかはわかりません。

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

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

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

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

右辺値参照メンバーが何を使用しているのか疑問に思いました

左辺値参照メンバーと比較して、利点または欠点はありますか？それの主なユースケースは何ですか？

したがって、右辺値参照に関するこの素晴らしい講義を見た後、Philippが動的に割り当てた場合、Philippが回答で指摘しているように、すべてのクラスがそのような「ムーブコンストラクター」、template<class T> MyClass(T&& other) 編集、そしてもちろん「ムーブ代入演算子」の恩恵を受けると思いました。template<class T> MyClass& operator=(T&& other)メンバー、または一般的にポインタを格納します。前述のポイントが当てはまる場合は、コピーコンストラクタ、代入演算子、およびデストラクタが必要です。考え？

RValue が暗黙の変換を許可しないという問題に遭遇しました。私の質問は、この制限を「バイパス」するのにどの実装が適しているかです。

問題を説明するためのコード例を次に示します。

RValue を使用できるが、関数がベースを必要とし、パラメーターが派生であるすべての呼び出しは失敗します。

オプション1

問題を修正するオプション 1:

このオプションでは、ユーザーは関数を呼び出す前に派生をベースにキャストする必要があります。これは、呼び出し元が変換の実際の基本型 (つまり、具体的なテンプレートのインスタンス化の基本型) を知る必要があるため、目的に反します。

オプション 2

問題を修正するためのオプション 2: (テンプレートを変更し、CallFunction をいくつか変更します)

呼び出し元は現在 RValue に課せられている制限を知らないため、オプション 2 の方が気に入っていますが、誰かが間違ったパラメーターを渡した場合に混乱を解消する十分な型チェック static_asserts があるかどうかはわかりません。

質問

1. オプション 2 に何か問題があると思いますか、それともオプション 1 の方が良いルートですか?

2. SFINAE を使用して型安全性をきれいにする方法はありますか?

次のことを考慮してください。

移動セマンティクスを最大限に活用するには、2番目のコンストラクターのようなコンストラクターを定義する必要がありますか？それとも、適切な状況で自動的に処理されますか？