問題タブ [generic-lambda]

明示的に型指定された変数にラムダを代入するとき (たとえば、関数自体をキャプチャするために再帰的である場合) を使用しますstd::function。

例として、このばかげた「ビット カウント」関数を考えてみましょう。

xC++14 ジェネリック ラムダで導入されたように、 auto パラメーターを使用して を一般化する場合はどうなるでしょうか?

明らかにauto、function型パラメーターを配置することはできません。

上記の正確なケースをカバーするのに十分な一般的なファンクタークラスを定義する可能性はありますが、関数定義にはまだラムダを使用していますか?

(これを過度に一般化しないでください。単一の auto パラメータのみを受け入れ、戻り値をハードコーディングします。) 使用例は、上記のようなシナリオの場合です: 再帰呼び出しの参照によって関数自体をキャプチャします。

次のようなファンクターのセットがあります。

それらをヘッダーファイルに保存するのは正しいですか? （副作用は？）

一般的なラムダ関数が与えられたときに非自動パラメーターの型を取得するコードをいくつか書きました。以下のコードでわかるように、一般的なラムダを使用して connect 関数を呼び出し、auto パラメーターに引数を提供するという考え方です (私のユース ケースでは常に先頭に配置されます)。したがって、以下のコードでの私の目標は、2 番目のパラメーターが float 型であることを検出することでした。

コードは clang 3.8 では正常に動作しますが、gcc 6.1.1 ではコンパイルされません。これは gcc のバグなのか、それとも有効な C++ コードではないのか疑問に思っていました。汎用ラムダがテンプレート化された operator() 関数で実装されていると仮定できますか、それともこれはコンパイラ固有のものですか?

gcc が与えるエラーは次のとおりです。

constfindArgTypesの を削除すると、同じ結果が得られます。

次のコードを使用すると、両方のコンパイラで機能します。

私が理解している限り、ジェネリックラムダは、テンプレート化されたローカルスコープ構造体のオブジェクトに変換されますoperator()。これにより、汎用ラムダが非常に強力で使いやすいツールになります。一方、構造体にテンプレート化されたメンバーがある場合は、関数にネストされた構造体を作成できます。

またはそれ自体がテンプレート化されています:

コンパイラのコンパイルに問題があるようです:

と

問題は、コンパイラのバグよりも C++ 標準にあると思います。ラムダがローカル構造ではなく、テンプレート化されたメンバーを持つことが許可されている理由は何ですか?

私はこの質問を見つけましたが、答えは時代遅れだと思います（c ++ 11でも真実ではないと思います）。

次のコードを検討してください。

GCCとclangの両方で問題なく動作します。
次のわずかに変更されたバージョンを考えてみましょう。

この場合、clang は引き続きそれを受け入れますが、GCC はそれを拒否します。

このコードを拒否する理由はありますか、それともコンパイラのバグですか?

私は問題を提起するつもりですが、一方ではなく他方では実装できた可能性のある提案が存在するかどうか知りたいです。

可変引数を持つジェネリック ラムダを返す関数を作成しようとしています。ラムダは、引数の 1 つが特定の値と等しいことを確認します。これが（大まかに）私がやろうとしていることです：

std::tuple</* ??? */>テンプレート引数に何を入れればよいかわかりません。decltype(args)、decltype(args...)、auto、およびその他いくつかのことを試しましたがauto...、コンパイラ エラーが発生し続けます。これは可能ですか？

非ジェネリックに相当するものは次のようになります。

これは問題なく動作しますが、返されるラムダは一般的ではありません。任意のパラメーター パックでは動作しません。