Шаблоны выражений + CRTP + AMP == генерация ядра

Недавно я обнаружил огромное количество шаблонов выражений и достиг некоторого удовлетворительного уровня понимания и навыков их использования, однако я хочу по-новому использовать эту идиому. Я бы пропустил длинную историю о том, как я пришел к этой проблеме, но вопрос доказывает себя с точки зрения стоимости.

Я пытаюсь создать классы базовых выражений, схожие с вики, но в C ++ AMP-совместимой форме, что означает, что все операции выполняются в ядрах C ++ AMP. Можно легко написать классы-обертки для таких больших векторных операций, в которых каждая элементарная операция является отдельным ядром, но это крайне неэффективно. Я пытаюсь создать классы шаблонов выражений, которые в конечном итоге объединяют операции в одно ядро.

Учитывая пример кода в вики, это будет означать, что внутри конструктора копирования класса Vec можно написать

concurrency::parallel_for_each(vec.get_extent(), [&](index_type i) restrict(amp,cpu) {...});

вместо обычного цикла for. Единственная проблема заключается в том, что внутри ограничивающих (amp) функций можно использовать только совместимые с amp классы, ограничения которых описаны в разделе 2 C ++ AMP спецификация, самое главное в разделе 2.4. Самое большое ограничение заключается в том, что C ++ AMP-совместимый класс не может иметь ссылок на члены, кроме как concurrency :: array. Это полностью уничтожает идиому Expression Tempalte (возможно, здесь используется неправильное слово), где операции упакованы друг в друга, и все они содержат ссылки на внутренние операнды. Хранение по значению AFAIK также не вариант, потому что компиляторы только «просматривают» классы, которые не имеют членов, кроме (const) ссылок.

Есть ли способ заставить это работать, или найти какой-нибудь альтернативный маршрут, который полностью на стороне хоста C ++ и в какой-то более поздний момент все приведено к C ++ AMP-совместимой конструкции? В конечном итоге я хотел бы иметь возможность создавать классы-обертки, которые люди, не знакомые с GPGPU, могли бы использовать ЭФФЕКТИВНО без необходимости создавать инструмент для генерации кода, вместо того, чтобы иметь компилятор для всей тяжелой работы.

Заранее спасибо.

пс .: естественно, index_type это параллелизм :: индекс<1>, а container_type — это concurrency :: array или concurrency :: array_view, в зависимости от того, что помогает решить проблему. Массив array_view является более чистым с точки зрения логики, это означает, что класс Vec создается с использованием массива вне класса, и Vec сохраняет только array_views в этот массив, однако array_views не допускаются как ссылочные члены в любой форме, плюс логически массив должен допускать больше оптимизаций компилятор, в отличие от того, чтобы каждая операция работала с разными массивами array_views, которые могут указывать на один и тот же физический массив.