My issue is very little relevant to OpenCL-GL interop, but since there is no OpenGL topic on the Khronos forum (???) neither is there a general section, I post here. There is opengl.org with it's own forum, most likely related to Khronos, there this question was already asked, but mainly users answered. Since my ultimate goal is an efficient interop application, this might be an adequate place to post.
I am shocked to see, that OpenCL which has been around for roughly 3 years has both C and C++ bindings (the proper usage of C/C++), while OpenGL which has been around for roughly 15 years still does not provide proper C++ bindings. All questions aiming at the existance of proper C++ bindings, people aswer: C API can be called from C++. However that is not what the question was.
The OpenCL C++ API shows really nice which elements of the API serve which pourposes. (I have been using the C API since the very beginning of OpenCL and just shifted to C++ recently) Although I could argue with it on some points (specially the buffer part), it is very well crafted.
What is the reason that OpenGL does not have anything like it? There are very similar API elements, but it seems just too C-like to see stuff:
I mean... I know that C++ objects are really almost like handles, so in practice what can be achieved with one can be done with the other also, but this is soooo not C++. Object orientation makes it easier to think also. All these obejcts serve different pourposes, so they should be different types, and functions relating to them should not be globally visible functions but those members of the corresponding classes.
I know that C API is capable of everything, but what is the reason that the need never arose in Khronos to create C++ bindings to such a widely-spread and powerful API as OpenGL? It would make our lives so much easier. I'm just learning OpenGL (not a complete newbie, but still have much to learn), and it would accelerate the process a lot) I know by the time it would be ready, I will most likely be a pro in the C API, but for future generations, or projects. (I would definately shift to C++ API if there was one) The statemachine nature of OpenGL would be a lot more easy to understand (and query and use it in code) if there were proper obejcts behind it.
There are many homebrew OpenGL C++ wrappers, but it just sounds too tedious to create homemade wrappers to something that should really be managed centrally by Khronos. I would not like to maintain code whenever OpenGL version is increased.
Any ideas or comments are appriciated.