私は最近、表現テンプレートの素晴らしさを発見し、その使用法についてある程度満足できるレベルの理解とスキルに達しましたが、イディオムを新たに使用したいと考えています。どうやってこの問題にたどり着いたかについての長い話は飛ばしますが、この問題は価値の点で証明されています。
wikiにあるものと同様の基本的な式クラスを作成しようとしていますが、C++AMP と互換性のある形式です。つまり、操作はすべて C++AMP カーネルで行われます。個々の基本操作を個別のカーネルとして持つような大規模なベクトル操作にラッピング クラスを簡単に作成できますが、これは非常に非効率的です。最終的に操作を単一のカーネルにマージするラッピング式テンプレート クラスを作成しようとしています。
wiki のサンプル コードを考えると、これは、Vec クラスのコピー コンストラクター内で次のように記述することを意味します。
concurrency::parallel_for_each(vec.get_extent(), [&](index_type i) restrict(amp,cpu) {...});
通常の for ループの代わりに。これに関する唯一の問題は、restrict(amp) 関数内では、C++AMP 仕様のセクション 2 、最も重要なセクション 2.4 で説明されている制限を持つ amp 互換クラスのみを使用できることです。最大の制限は、C++AMP 互換クラスが、concurrency::array 以外の参照メンバーを持つことができないことです。これは Expression Tempalte のイディオム (ここでは間違った言葉を使用している可能性があります) を完全に破壊します。そこでは操作が互いにパックされ、すべて内部オペランドへの参照が保持されます。コンパイラは（const）参照以外のメンバーを持たないクラスのみを「シースルー」するため、AFAIKの値による格納もオプションではありません。
これを機能させる方法、または完全にホスト側の C++ であり、後ですべて C++AMP 互換の構造にキャストする代替ルートを見つける方法はありますか? 最終的には、GPGPU の知識がなくても、コード生成ツールを作成しなくても効率的に使用できるラッピング クラスを作成できるようになりたいと考えています。
前もって感謝します。
ps .: 当然、index_type は concurrency::index<1> であり、container_type は concurrency::array または concurrency::array_view のいずれかで、問題の解決に役立ちます。array_view は論理的にきれいです。つまり、Vec クラスはクラス外の配列を使用して作成され、Vec は array_views のみをその配列に格納しますが、array_views はどのような形式でも参照メンバーとして許可されません。さらに、論理的に配列は、実際には同じ物理配列を指している可能性のある異なるarray_viewですべての操作を実行するのではなく、コンパイラー。