STRING_CLASS and VECTOR_CLASS

I’m pretty new to OpenCL, but I’ve “found” a bug, well, not really a bug, but an inconsistency in the c++ wrapper header files.

STRING_CLASS is a typedef, thus requiring the use of a namespace ala cl::STRING_CLASS
VECTOR_CLASS is a #define, thus requiring the use of NO namespace ala VECTOR_CLASS (cl::VECTOR_CLASS will generate a compiler error)

They should probably both be the same…

Do I NEED them to be? Of course not, but over-generalization is kind of a hobby, and I spotted some abstracted types to use, first saw VECTOR_CLASS, then STRING_CLASS in function definitions, and it took me a good 20 minutes to figure out that STRING_CLASS needed the namespace…

My preference is that both would be typedefs in this case, namespaces are nice anti-name collision machines, and VECTOR_CLASS and STRING_CLASS are both very generic names that could potentially collide, oh the havoc VECTOR_CLASS would cause if I tried to implement my own abstraction imagine the compiler interpreting typedef std::vector VECTOR_CLASS as typedef std::vector std::vector…

The latest version of the C++ bindings (cl2.hpp) deprecates the STRING_CLASS and VECTOR_CLASS mechanisms, and replaces them with aliasing inside the cl namespace. Here’s the description from the comments in the top of the header:

 * The earlier versions of the header included basic vector and string          
 * classes based loosely on STL versions. These were difficult to               
 * maintain and very rarely used. For the 2.0 header we now assume              
 * the presence of the standard library unless requested otherwise.             
 * We use std::array, std::vector, std::shared_ptr and std::string              
 * throughout to safely manage memory and reduce the chance of a                
 * recurrance of earlier memory management bugs.                                
 *                                                                              
 * These classes are used through typedefs in the cl namespace:                 
 * cl::array, cl::vector, cl::pointer and cl::string.                           
 * In addition cl::allocate_pointer forwards to std::allocate_shared            
 * by default.                                                                  
 * In all cases these standard library classes can be replaced with             
 * custom interface-compatible versions using the CL_HPP_NO_STD_ARRAY,          
 * CL_HPP_NO_STD_VECTOR, CL_HPP_NO_STD_UNIQUE_PTR and                           
 * CL_HPP_NO_STD_STRING macros.  

Hmm, guess I’ll remove the abstracted names from my code then, seems pretty unlikely the vector and string types used in the API would change, and I’ll probably never need anything other than the STL implementation anyway, unless I find a very particular performance problem that gets propagated into my parallel code somehow with the STL versions… But at the moment I’m not planning on processing any strings, and my data types will be custom-defined abstractions of physical data.

Another interesting note, the AMD APP SDK 3.0 that supports OpenCL 2.0 apparently comes with an old OpenCL 1.2 C++ header (cl.hpp instead of cl2.hpp)

Think I’ll download all of the official Khronos ones instead just to be on the safe side…