問題タブ [universal-reference]

範囲ベースのforステートメントは、§6.5.4で次と同等に定義されています。

ここで、range-initは範囲ベースの2つの形式に対して次のように定義さforれます。

（この節は、他の部分式の意味をさらに指定します）

なぜ__range推定型が与えられるのauto&&ですか？私の理解でauto&&は、式を通過させることにより、式の元の値（左辺値/右辺値）を保持するのに役立つということですstd::forward。ただし、__rangeはどこにも渡されませんstd::forward。__range、、、__range.begin()またはのいずれかとして、範囲イテレータを取得する場合にのみ使用されますbegin(__range)。

ここで「ユニバーサルリファレンス」を使用する利点は何auto&&ですか？auto&十分ではないでしょうか？

注：私が知る限り、提案はの選択について何も述べていませんauto&&。

ユニバーサル参照パラメーターを取る関数テンプレートを特殊化するにはどうすればよいですか?

foo.hpp:

foo.cpp

ここで、Classはもはや推定型ではなく、したがってClass正確です。になることはあり得ないClass &ので、参照の折りたたみルールはここでは役に立ちません。おそらく、パラメーターを取る別の特殊化を作成できますがClass &(よくわかりません)、fooすべてのパラメーターの右辺値/左辺値参照の可能な組み合わせごとに含まれるすべてのコードを複製することを意味します。これは、ユニバーサル参照が回避することになっているものです。 .

これを達成する方法はありますか？

問題を解決するためのより良い方法がある場合に備えて、私の問題をより具体的に説明するには:

複数のゲーム サーバーに接続できるプログラムがあり、ほとんどの場合、各サーバーはすべてを同じ名前で呼び出します。ただし、いくつかの点でわずかに異なるバージョンがあります。これらのものには、移動、アイテムなど、いくつかの異なるカテゴリがあります。私は、内部コードが呼び出す関数の一般的な種類の「文字列を移動して列挙型を移動する」関数セットを作成しました。機能。ただし、一部のサーバーは、通信する独自​​の内部 ID を持ち、文字列を使用するサーバーもあれば、さまざまな状況で両方を使用するサーバーもあります。

ここで私がやりたいことは、これをもう少し一般的なものにすることです。

のようなものを呼び出せるようにしたいServerNamespace::server_cast<Destination>(source)。Moveこれにより、 aから astd::stringまたはにキャストできますServerMoveID。内部的には、一部のサーバーでは送信されたメッセージの履歴を保持する必要があるため、コピーを作成 (または移動) する必要がある場合があります。ユニバーサル参照は、この問題に対する明らかな解決策のようです。

私が今考えているヘッダーファイルは、これを単純に公開します：

また、実装ファイルは、すべての正当な変換をテンプレートの特殊化として定義します。

メンバー変数、コピー可能および移動可能なタイプのそれぞれ、および対応するセッター関数をX持つクラスについて考えてみます。C ++ 98では、の定義は次のようになります。NNX

上記のクラスのセッター関数はX、左辺値と右辺値の両方の引数にバインドできます。実際の引数によっては、これにより一時的なものが作成され、最終的にはコピーの割り当てが発生する可能性があります。このため、コピーできないタイプはこのデザインではサポートされていません。

C ++ 11では、移動セマンティクス、完全な転送、およびユニバーサル参照（Scott Meyersの用語）があり、次のように書き直すことで、セッター関数をより効率的かつ一般的に使用できます。

ユニバーサル参照は、/ non -、/ non- const、および一般に任意の変換可能なタイプにバインドできるため、一時的なものの作成を回避し、値をに直接渡すことができます。コピー不可能な移動可能なタイプがサポートされるようになりました。おそらく望ましくないバインディングは、を介して、またはを介して排除できます。constvolatilevolatileoperator =static_assertstd::enable_if

だから私の質問は：設計ガイドラインとして、C ++ 11のすべての（たとえばほとんどの）セッター関数は、ユニバーサル参照を受け入れる関数テンプレートとして作成する必要がありますか？

より厄介な構文と、これらのセッター関数でコードを記述するときにIntellisenseのようなヘルパーツールを使用できないことは別として、「可能な場合はいつでもユニバーサル参照を受け入れる関数テンプレートとしてセッター関数を書く」という仮定の原則に関連する欠点はありますか？

クラス内にユニバーサル参照を保存する必要があります（参照された値はクラスよりも長く存続すると確信しています）。そうする標準的な方法はありますか？

これは私が思いついたものの最小限の例です。うまくいくようですが、うまくいったかどうかはわかりません。

私の推論は正しいですか、それとも微妙なバグにつながるのでしょうか? また、コンストラクタを記述するためのより良い (つまり、より簡潔な) 方法はありますか? binder(F&& f, X&& x)これらは右辺値参照であるため、機能しませんbinder(f, i)。

1. make_tupleから戻るときに、（RVOなしで）コピー/移動が含まれていますか？
2. 未定義の動作を引き起こしていますか？
3. 私は両方ともユニバーサルリファレンスを読み書きできます。コピー/移動がないように、auto&& var = func()代わりに常に使用できますか？auto var = func()

以下では&&、ユニバーサルリファレンスですか？

標準 C++11 でオプションの参照を使用するためのトリックを見つけました。この手法は信頼性が高く、動作は C++ 標準に従って明確に定義されていると思いますか?

結果は次のとおりです。

liveworkspace : LWSで利用可能なすべてのコンパイラで動作するようです。

intr値またはl値(const)参照によって、パラメータ(具体的な型、たとえば )をメンバー関数に渡したいと考えています。私の解決策は次のとおりです。

別の例はここhttp://pastebin.com/9kgHmsVCです。

しかし、それは冗長すぎます。より簡単な方法でそれを行う方法は？

の代わりにstd::remove_referenceとの重ね合わせを使用する必要があるかもしれませんが、ここでは単純化しています。std::remove_conststd::decay

ユニバーサル参照によって任意の型を受け入れることができる関数があり、特定の型に対してオーバーロードしたいと考えています (そのうちのいくつかはそれ自体がテンプレート化されていますが、ここでは重要ではないと思います)。残念ながら、オーバーロードを正しい順序で解決することはできないようです。

の 2 番目の宣言は、より具体的である (テンプレート化されていない) ため、優先されると推測していましたがfoo、オーバーロードの解決に関する私の理解がやや不足しているようです。興味深いことに、2 番目の宣言をX値で受け取るように変更すると、「良い、良い」とX出力され、非 const 参照で受け取ると「悪い、良い」と出力されます。明らかに、最初の宣言を完全に削除すると、他に選択肢がないため、「良い、良い」が返されます。

では、なぜこれが起こるのですか？そして最も重要なことは、次のコードが機能しない場合、このシグネチャを使用して関数をオーバーロードするにはどうすればよいでしょうか?

編集：

おそらく、これに対するより遠回りな解決策は、間接的に行うことです。の最初の形式を取り除き、fooSFINAE を使用して有効なオーバーロードが存在するかどうかを確認しますfoo_fallback。