1 of 1 people found this helpful
A scoped_array would work, but boost wasn't a possibility here for two reasons. The first is that boost was disallowed int he design, the second is that scoped_ptr would do a heap allocation which is, I think, not allowed in the C++ bindings as per the requirements (they would be unusable for too many people if they did heap allocation).
The C++ bindings could certainly do with more documentation. The purpose of those get methods is to support default platforms, queues etc that we were unable to support in the standard OpenCL interfaces.
Thanks for confirming my understanding of the functions.
The bit about scoped_array<> was simply meant as an example of an alternate approach, though I agree with your decision not to introduce a boost dependency. Given the availability of a C interface that's already optimized for use on heavily restricted platforms, my own opinion would be to aim a bit higher, with the C++ interface. Though I have the luxury of having opinions without responsibility in the matter.
I suppose alloca() could have portability implications, but I guess those can be addressed if & when necessary.
One idea worth considering might be to place nonstandard extensions in a subclass. That would tend to minimize conflicts with future versions of the the standard. The subclass could even have the same name, differing only in the namespace in which it exists.