問題タブ [rvalue]

次のように、関数テンプレートが非 const 左辺値の場合に左辺値性を維持しながら引数を転送する必要があるが、それ自体は引数が実際に何であるかにとらわれない状況を考えてみましょう。

xが右辺値の場合T、定数型に推定されるのではなく、エラーが発生します。

右辺値を (明示的forwardなテンプレート引数を呼び出さずに) 処理するには、forward(const T&)本体が完全に複製されていても、オーバーロードが必要なようです。

この重複を避ける方法はありますか?

1を超える深さから返された右辺値参照を渡すときに問題が発生しました。

std::vectorはダブルフリーになっていると思います。g ++（Ubuntu / Linaro 4.4.4-14ubuntu5）4.4.5を使用しています

上記のコードはあなたのために働きますか？私は何か間違ったことをしていますか、それともライブラリまたはコンパイラにバグがありますか？

（天国が）それがコンパイラである場合（gccには他の既知のC ++ 0xバグがあります）、ubuntuでgccをアップグレードまたはパッチするための適切な安全な方法があるかどうか誰かに教えてもらえますか？以前に試しましたが、サポートされていないパッケージが絡み合っています。

どうもありがとう。

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

これを許可する設計上の根拠は何ですか

しかし、これではありません

?

2 行目で何が問題になる可能性がありますか (最初の行ではまだ問題が発生していません)。

is_callable<F, Args...>少し前に、トレイトを書きたいときに、いくつかのコードの次の動作に混乱しました。過負荷の解決では、非定数refによる引数を受け入れる関数は呼び出されませんよね？コンストラクターが必要なため、次のように拒否しないのはなぜTest&ですか？かかると思っていましたf(int)！

エラーメッセージは

一方が機能するのにもう一方が機能しない理由を説明していただけますか？

C ++では、コピーではなくインクリメントされたオブジェクト自体が返されるため、pre-increment演算子は左辺値を返します。しかし、Cでは、それは右辺値を与えます。なんで？

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

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

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

オプション1

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

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

オプション 2

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

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

質問

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

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

std::bindC++0xで右辺値参照を受け取る関数に右辺値を渡したい。どうしたらいいのかわからない。例えば：

次のコードがどのようにコンパイルされるか、またはコンパイルされないかがわかりません:

g++ 4.4.4 を使用しています。

私はインターネットでかなり多くのことを読んでいますが、多くの人が次のルールについて言及しているようです（しかし、私はそれを標準で見つけることができませんでした）、

加算演算子+（および他のすべての二項演算子）では、両方のオペランドが右辺値である必要があり、結果は右辺値になります。等々..

C ++標準を確認したところ、（3.10 / 2節）と明確に述べられています。

prvalueが期待されるコンテキストでglvalueが表示されると、glvalueはprvalueに変換されます。

（5/9節）、

glvalue式が、そのオペランドのprvalueを期待する演算子のオペランドとして表示される場合は常に、左辺値から右辺値（4.1）、配列からポインター（4.2）、または関数からポインター（4.3）の標準変換が行われます。式をprvalueに変換するために適用されます。

これは、オペランドがprvalueを「期待する」という用語を使用します。ただし、加算演算子、乗算演算子などを調べると、結果はprvalueであるとしか言及されていませんが、オペランドが「期待される」ものについては何も述べられていません。

二項演算子が実際にオペランドがprvalueであることを期待しているかどうかは、次の場合に違いがあります。

bがprvalueであると予想される場合、ここで左辺値から右辺値への変換が行われ、次にprvalue + prvalueが実行され、prvalueが返され、結果のprvalueが左辺値aに割り当てられます。

ただし、bがprvalueである必要がない場合は、lvalue + prvalueになり、結果はprvalueになります。

標準が明示的または暗黙的にさまざまな演算子のルールについて言及している場所を本当に知りたいですか？私はすべての演算子のセクションをチェックし、オペランドと結果が左辺値か右辺値かを標準で明示的に言及している演算子はごくわずかです。ほとんどの演算子の場合、標準では結果のみが記載されており、オペランド要件は記載されていません。

ありがとう。

ところで、定数式に関する標準5.19で、二項演算子がオペランドで左辺値から右辺値への変換を必要とすることを非常に「暗黙的に」暗示している可能性があることを発見しました。詳細については、前の質問を参照してください。

constexprとconstの混合使用？

条件式は、評価される可能性のある部分式として次のいずれかが含まれない限り、定数式です（3.2）。

..。

—左辺値から右辺値への変換（4.1）

————定数式で初期化された、先行する初期化を伴う不揮発性constオブジェクトを参照する整数型または列挙型のglvalue

読んでくれてありがとう。