問題タブ [perfect-forwarding]

std::forwardへの引数として使用する場合、関数パラメーターを使用する必要がありますstd::forward_as_tupleか?

それらが右辺値参照として格納されることはわかっていますが、他に考慮すべきことはありますか?

次のシグネチャは、std::forwardオーバーロードとして宣言されています。

ここで、次のテンプレート関数を検討してください。

私が書く場合：

次に、コンパイラがインスタンス化する方法はfoo_as_always次のT = int&とおりです。

そして、私が書くと：

次に、コンパイラは次のようにインスタンス化foo_as_alwaysしT = intます。

どちらの場合も、t変数は式の左辺値です。std::forwardコンパイラは、関数のどのオーバーロードを呼び出す必要があるかをどのように認識しますか?

printf()-スタイルのログ機能を提供するサードパーティの C ライブラリを使用しています。

踏み込む価値のない理由から、メッセージがログに記録される速度を制限する必要があります。

幸いなことに、C ライブラリの作成者は自分たちが何をしているのかを知っていたので、

したがって、上記の関数を書くことは比較的簡単なことです。残念ながら、可変個引数関数は inliningではうまく機能しないため、2 番目の解決策を思いつきました。

これは完全に機能し、必要に応じてレート制限条件をインライン化します。しかし、それについていくつか質問があります。

• このようにパラメーター パックを C スタイルの可変引数関数呼び出しに展開することは、C++11 で行うべき正当で明確に定義されたものですか? それとも、それが機能するという幸運に恵まれたのでしょうか?

• C関数を呼び出しているとすれば、実際にここで&&andが必要ですか? を使用しても、値だけでもstd::forward、 を使用しても使用しなくても、同様に機能するようです。const T&Tstd::forward

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

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

ライブデモ。

私は C++14 用の JSON ライブラリを作成しており、可能な限り移動セマンティクスを利用しようとしています。

私Valueのクラスには、可能な場合は常に移動しようとするセッターとゲッターがいくつかあります。

コードからわかるように、完全な転送セッター関数は、テンプレートとユニバーサル参照を使用して非常に簡単に作成できます。

ゲッター関数で同じことを行うにはどうすればよいですか? テンプレートの戻り値の型を使用する必要があることは確かですが、ref-qualifiers と const-correctness を複製する方法がわかりません。

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 プリミティブを除いて、あまり気にする必要はないと言う人もいます:

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

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

ファンクター呼び出しを転送し、絶対に必要な場合にのみそのファンクターをコピーしたいと思います。これが私の一般的なラッパー関数とファンクターです:

ラッパーを呼び出すことができます

1. 右辺値参照: wrapper( Functor() );
2. 左辺値参照: ファンクター f; ラッパー（f）;
3. const 左辺値参照: const Functor f; ラッパー（f）;
4. const 右辺値参照: const Functor make_functor (); ラッパー (make_functor ());

const 参照が渡された場合にのみラッパーの arg をコピーしたい。だから私はそのようなラッパーの実装に来ます:

あまり良くなく、（あまり典型的ではない）const-rvalue-referenceのケースを見逃していますが、基本的には機能します。

しかし、const operator() を持つ Functor もあるかもしれません

その場合、ラッパーの引数をまったくコピーする必要はありません。

問題は、 Functorに const 括弧演算子がある場合、ラッパーをチェックインするにはどうすればよいかということです。もう 1 つの質問は、ラッパーが、膨大な数の型特性 typedefs の行なしで、よりスマートでコンパクトな方法で実装できるかどうかです。(実際には、コードのサイズではなく、コードの可読性について心配しています)。