Archives Discussions

[craft_coder]

I'm reading through the C++ header file supplied with the 2011-12-19 release of the AMD APP SDK.

I noticed an unimplemented static member function:

     const cl::Platform cl::Platform::null()

It has no docs.  What is that all about?

Also, I was trying to sort out what this function did:

    static cl_int cl::Platform::get(cl::Platform *platform)

Also no docs.  It appears to assign the pointer with a new Platform that's constructed from the first Platform ID.  I actually thought there was a memory leak, but then I looked up alloca().  I'd have just used a boost::scoped_array<> for that.

This appears to do the same thing, though returning the first Platform instead of assigning it through a provided pointer:

    static cl::Platform cl::Platform::get (cl_int *errResult=NULL)

Does anyone know if these are in the standard?  Is there any other doc describing the C++ interface besides opencl-cplusplus-1.1.pdf on Khronos' site?

[LeeHowes]

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.

[craft_coder]

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.