問題タブ [forwarding-reference]

あなたが次のようなコードを読んだ場合

auto&& var = foo();

ここで、fooはタイプの値で返される関数ですT。次にvar、を参照する型右辺値の左辺値ですT。しかし、これは何を意味するのvarでしょうか？それは、私たちがの資源を盗むことを許されているということvarですか？あなたが独占的な所有権を持っていることを伝えるためauto&&にあなたが戻ったときのようにあなたがあなたのコードの読者に何かを伝えるために使うべきである合理的な状況はありますか？unique_ptr<>そして、たとえば、クラスタイプのT&&場合はどうでしょうか。T

auto&&テンプレートプログラミング以外のユースケースがあるかどうかを理解したいだけです。この記事の例で説明されているもののように、ScottMeyersによるUniversalReferencesです。

これは右辺値参照です。

左辺値にはバインドしません。

これは普遍的な参照です:

右辺値にバインドし、左辺値にもバインドします。

これは右辺値参照です。

左辺値にはバインドしません。

ユニバーサル参照が右辺値参照と同じ構文を使用するのはなぜですか? それは不必要な混乱の元ではありませんか? T&&&委員会は、 、T&*、T@またはT&42(最後のものは冗談です) のような代替構文を検討したことがありますか? もしそうなら、代替構文を拒否する理由は何でしたか?

型消去機能を備えた小さなポリモーフィック クラスを開発したいのですが、テンプレート化されたコンストラクターのどのバージョンが優れていて、使用する必要があるのか​​疑問に思っています。

値で渡すことができます：

または、ユニバーサル参照を使用できます。

T(クラス自体ではなく、クラスがコピーされない場合は、ユニバーサル参照を有効にする必要があります)。何か案は？どちらのバージョンも私には同じように見えます。

ユニバーサル リファレンスで遊んでいるときに、clang と gcc がオーバーロードの解決について意見が一致しないこのインスタンスに出くわしました。

gcc は、上記の呼び出しがあいまいであると報告しています。ただし、clangはオーバーロードを選択し、T&正常にコンパイルします。

どのコンパイラが間違っていますか? その理由は?

編集:
VS2013 プレビューで同じコードをテストし、clang に同意します。gcc側にあるIntellisenseを除いて:-)

に関して。提案された重複「値渡しはC++ 11の妥当なデフォルトですか?」-そこの質問も答えも、「ユニバーサル参照」コンストラクターのバージョンについて言及していないため、重複を実際に確認できません。再開を検討します。

私は移動のセマンティックに慣れ、それを試しています。この（コンパイル可能な）コードを見てください：

出力：

http://coliru.stacked-crooked.com/a/3be77626b7ca6f2c

どちらの関数も、どちらの場合でも適切に機能します。値渡し関数は移動コンストラクターをもう一度呼び出しますが、これは安価なはずです。あるパターンが他のパターンよりも優先されるべき状況についてコメントしていただけますか?

C++11 より前は、次のようなコードを書いていました。

しかし、移動セマンティクスを使用すると、(少なくとも場合によっては) 関数が右辺値参照をパラメーターとして取り、これらのオーバーロードを追加できるようになる可能性があります。

私が集めたものから、大きな関数内でこれらのオーバーロードを呼び出せるようにしたい場合は、次のように見える完全な転送を使用する必要があります (少し読みにくいですが、テンプレート タイプの適切な命名規則):

私の問題はこれです:私の小さな関数に他のオーバーロードがある場合、意図されていない型のパラメーターを使用して大きな関数を呼び出すことが可能になるということではありませんか?

これを防ぐためにこれが機能する可能性があると思います：

A、B、または C に暗黙的に変換可能な型で大きな関数を呼び出そうとすると、どのように動作するかがわからないため、制限が厳しすぎるかどうかはわかりませんが...

でも... これでうまくいくとしても、本当に他に選択肢がないのでしょうか? (というか…目に優しくない)

以下のコードには、「ユニバーサル参照」を受け入れる関数があります ( F&&)。F&&関数には、コンストラクターでのオブジェクトを受け入れる内部クラスもあります。F&&その時点でまだ普遍的な参照ですか？つまり、Fまだ推定型と見なされますか?

つまり、コンストラクターの初期化リストでstd::forward<F>orを使用する必要がありますか?std::move

ライブデモ。

Herb Sutter の基本に戻る! CppCon での Essentials of Modern C++プレゼンテーションでは、パラメーターを渡すためのさまざまなオプションについて説明し、それらのパフォーマンスと記述/教育の容易さを比較しました。「高度な」オプション (テストされたすべてのケースで最高のパフォーマンスを提供しますが、ほとんどの開発者が書くには難しすぎる) は、次の例で完全な転送でした(PDF、28 ページ) :

この例では、テンプレート パラメーターStringをenable_if. ただし、制約は正しくないようです。このメソッドは、String型が astd::stringでない場合にのみ使用できると言っているようですが、意味がありません。つまり、このstd::stringメンバーは値以外を使用して設定できますstd::string。

私が考えた 1 つの説明は、単純なタイプミスがあり、制約が のstd::is_same<std::decay_t<String>, std::string>::value代わりになることを意図していたというものでし!std::is_same<std::decay_t<String>, std::string>::valueた。ただし、それはセッターが動作しないことを意味します。たとえば、const char *プレゼンテーションでテストされたケースの 1 つであることを考えると、明らかにこの型で動作することを意図していました。

正しい制約は次のように思われます。

メンバーに割り当てることができるものはすべてセッターで使用できます。

適切な制約がありますか? 他に改善できる点はありますか？元の制約についての説明はありますか?おそらく文脈から外されたのでしょうか?

また、この宣言の複雑で「教えられない」部分が本当に有益なのだろうかと思います。オーバーロードを使用していないため、通常のテンプレートのインスタンス化に単純に依存できます。

そしてもちろん、本当に重要かどうかについてはいくつかの議論がありnoexcept、move/swap プリミティブを除いて、あまり気にする必要はないと言う人もいます:

おそらく、概念があれば、単にエラー メッセージを改善するために、テンプレートを制約することは不当に難しくないでしょう。

これにはまだ仮想化できないという欠点と、ヘッダーになければならないという欠点がありますが (モジュールが最終的にその問題を解決することを願っています)、これはかなり教えられるようです。

Forwarding Reference (以前はScott Meyers によってUniversal Referencesと呼ばれていました) のデフォルト引数を指定する方法を理解するのに苦労しています。

私がやりたいことをしようとしているコードの例を次に示します。

Coliru でも利用できます。

エラーを調べてみると、テンプレート引数をデフォルトに設定し、その後引数をデフォルト構築することで機能させることができることがわかりました。

コリルにも。

これはこれを処理する「適切な」方法ですか？私が使用する構文は何ですか？「デフォルトの転送参照」の望ましい効果を得る方法は複数ありますか? これはどのように書けばよいのでしょうか？また、後でコードに大量の SFINAE を振りかけることになるので、複数のオーバーロードの記述を含まないものをはるかに好むことを覚えておいてください。