問題タブ [perfect-forwarding]

次のコードが有効かどうかを知りたいです。
特に、new_S を呼び出した後の、ここに含まれるオブジェクトの有効期間について混乱しています。
私の理解では、初期化リストを処理するときに T がコピーされ、おそらくベクトル移動コンストラクターでコピーされます。
RValue ベクトルはどうですか? new_S から戻った後も有効ですか? 私はノーと言うだろうが、私は絶対に確信が持てない

template のオーバーロード解決でビットフィールドの回避策を探しています。

引数を完全に転送するためにテンプレート化した関数があります。

次のように、ビットフィールド引数で使用しようとすると:

…コンパイルに失敗します:

f()ビットフィールドを値で受け取るが、一般的なケースで他の引数を参照で受け取るようにオーバーロードする方法はありますか?

これまでのところ、私はできませんでした。たとえば、引数を値で受け取るオーバーロードを追加すると…</p>

に引数を渡すよりも、その引数を出力するprint_args別のクロージャー、たとえば、を受け取るクロージャーを作成したいと思います。ff

これに対する私の最初の試みは次のとおりです。

したがって、以下も定義するとします。

次に、次のことができます。

見てわかるように、print_args_addはただのクロージャーでありadd、引数を出力します。

を定義することもできますsum:

同様に：

これは、s を渡す場合にうまく機能しarrayListます。ただし、通常の配列を渡す場合:

正常に動作しますが、次のとおりです。

クロージャーprint_argsが渡された配列をそのまま渡すのではなく展開するため、壊れます。

呼び出し元やクロージャーが処理できるものに追加の制約を課すことなく、単一の配列を引数として渡すことができるprint_argsクロージャーを処理できるように書く方法はありますか?fprint_args

コードを ideone hereに配置しました。

演算子の名前が気に入らず、セマンティクスを完全に保持しながらstatic_cast、別の名前の関数にラップしたいとします。fancy_static_castどうすればいいですか？より具体的にはstatic_cast、値または参照によって引数を受け入れますか? それとも引数式に依存するのでしょうか？いくつかのオーバーロードを提供する必要がありますか、それともこのようなものでうまくいきますか?

次のコードを直接持っています: http://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html

g++ 4.8.1 で次のようにコンパイル: g++ -std=c++11 testforward.cpp -o testforward.exe

著者によると、以下に説明します。

右辺値参照を関数テンプレートと組み合わせると、興味深い相互作用が得られます。関数パラメーターの型がテンプレート型パラメーターへの右辺値参照である場合、左辺値が渡された場合、型パラメーターは左辺値参照であると推定されます。それ以外の場合は入力...

このテストの結果出力は次のとおりです。

f(x) get "t in g is lvalue" は期待どおりです !!

f(X()) get "t in g is rvalue" 、はい、それが std::forward に使用されたものです

h(X()) get "t in g is lvalue" 、これは私の質問です。関数 h はテンプレート関数ではないことがわかります。著者が説明しているように、「右辺値参照を関数テンプレートと組み合わせると、興味深い結果が得られます。相互作用」はそうではありませんが、それでもこの関数出力「t in g is lvalue」は、この興味深い相互作用がテンプレート関数だけでなく、通常の関数にも発生することを意味します!!

コードを次のように変更すると:

「t in g is rvalue」が得られます!!!

テストによると、作者は「右辺値参照を関数テンプレートと組み合わせると、興味深い相互作用が得られる」と説明していると言いましたが、実際にはテンプレート関数だけでなく、通常の関数にも適用されます。または、私の英語が苦手なので、できますこの説明を聞き取れませんよね?!

編集 ：

テンプレート関数のみのように見えますが、std::forward の cprrect 使用法を取得します !!!

C++ の暗黙的なコピー コンストラクターに関する私の理解は、次のようになります。

移動コンストラクター、コピー & 移動代入も同様のパターンに従います。

次のように定義されなかったのはなぜですか?

例

暗黙のコピー/移動コンストラクター/代入演算子と、いくつかの変換コンストラクターを持つクラスがありました。私は仕事をいくつかの実装クラスに委任していました。

work1コピー/移動コンストラクターが のコピー/移動コンストラクターを呼び出してcommon_workおり、別の種類の から変換する他のコンストラクター [コードには表示されていません] によって転送コンストラクターが使用されていたため、これは問題ありませんでしworkた。

work1その後、EBO などのcommon_work理由でを継承しようと考えました。新しいwork1クラスは次のようになりました

しかしwork1、work_likeクラスであるため、突然転送コンストラクターがより適切に一致common_workするstatic_castようになりました。

ノート ：

• Scott Meyersによって与えられた同様の種類の例があり、コピー コンストラクターには const の追加が必要なため、コピー コンストラクターは転送コンストラクターをトリガーしますが、転送コンストラクターには何も必要ありません。しかし、この問題は間違ったクラス設計が原因で発生すると思いますが、ここでの問題は、暗黙的なコピー/移動中に基本クラスに渡される引数が完全に一致しないことが原因です。
• 削除された関数もオーバーロード解決に参加し、正確に一致するとエラーが発生するため、ユニバーサル転送コンストラクター/割り当てを記述して暗黙的なものを削除することはできません。
• 現在私が持っている解決策はcommon_work、 CRTP として作成することです。つまり、派生クラスの型をテンプレート引数として渡し、転送コンストラクターでそれを としてフィルター処理しenable_if<and_<work_like<T>,not_<is_same<T,Derived> > > >ます。work1そうしないと、基本クラスのコピー/移動コンストラクター/割り当てをstatic_cast明示的に手動で作成する必要があり、バグが発生しやすく、エラーが発生しやすく、メンテナンスが危険です。

Boost.Move/other Boost ライブラリの助けを借りて転送セマンティクスを必要とする C++03 プロジェクトに取り組んでいます。プロジェクトの目標は、unique_ptr を C++11 に前方互換性のある方法で提供することです。

C++11 標準では、次のコンストラクターが必要です。

格納されたデータを u から転送し (基本的には ptr_val = u.release())、次のようになります。

• E が参照型の場合、u のデリータを *this にコピーします。
• それ以外の場合は、u の削除子を *this に移動します。

テストでは、このコードは「機能する」ようです。

これでカバーできない重要なケースはありますか?

次の構造体テンプレートを検討してください。

ここで、T は左辺値参照 (例: const int&) または通常の値 (例: )のいずれかになりますint。アイデアは、 lvalueXから構築されるときは常に lvalue-reference を使用し、 rvalueから構築されるときは通常の値を使用することです。

したがって、次のファクトリ関数は、そのXようなプロパティを持つのインスタンスを作成するために定義されています。

ここまでは順調ですね。構造体テンプレートを考えるとY:

そして、 について前と同じ類推を行うことに決め、X最終的には次の 4 つのファクトリ関数になります。

同じ結果を得る別の方法はありますか?おそらく冗長ではありませんか? 幸いなことに、私のアプリケーションは 2 つ以上のテンプレート データ メンバーを必要としませんが、その他のいくつかのクラスYが必要になり、それぞれに 4 つのファクトリ関数が必要になります。