Hi!
I would like to open this topic as a placeholder for everyone to make suggestions about the 'standard' C++ wrapper of OpenCL, cl.hpp. Let me start off by a little brainstorming, suggestions and questions about the wrapper:
If anyone else has ideas, comments, feel free to share it. And naturally, we are eager to recieve corporate feedback.
vector<cl::EnqueueArgs> m_args;
cl::EnqueueArgs a(cl::NDRange(1024));
m_args.push_back(a);
produce this error /usr/include/CL/cl.hpp:5482: error: 'cl::EnqueueArgs& cl::EnqueueArgs::operator=(const cl::EnqueueArgs&)' is implicitly deleted because the default definition would be ill-formed: which is similar to yours error. It seems like C++ compiler desn't generate default = operator because it will cause error.
Your friendly cl.hpp maintainer here.
The problem is that the goal of the header was to be *very* thin, with no state. We had to break that in one case to maintain compatibility with pre-1.2 runtimes (reference counting of devices caused an issue), but adding further state to buffers etc would break the design goals. That's not to say that STL-style container types wouldn't be useful, it's just that it isn't covered by the goals of the design and would break backward compatibility in this case. We could easily add more constructors, though. Maybe adding a copy constructor to EnqueueArgs is necessary too, so I'll look into that if I can.
C++11 changes would be nice, but not portable enough just yet. C++11 in the AMD OpenCL implementation isn't really an issue, the OpenCL APIs are C, after all. C++11 in the header is a wider problem of portability for users' compilers. Adding futures would be very clean but add a lot of extra versioning for the time being.
Splitting the header in the way nou suggests is something I've been thinking about for a while. Remember that cl.hpp is an official Khronos header. Changes have to be run past the working group. It's always going to be a more conservative design than an arbitrary open source project might be.
Nou,
BOLT is slightly higher than C++AMP. It can actually (theoretically) use C++AMP as its backend - just like how it currently uses OpenCL as its backend.
This is what I remember after viewing Kent Knox's session. Correct me, if I am wrong here.