I can see the temptation for a very simple bare-bones C++ wrapper, one can have things like this:
class GLTextureHandle
{
public:
GLuint m_name;
void
TextureParameter(GLenum pname, const GLint *v)
{
glTextureParameterivEXT(m_name, pname, v);
}
void
TextureParameter(GLenum pname, const GLfloat *v)
{
glTextureParameterfvEXT(m_name, pname, v);
}
template<unsigned int N, typename T>
void
TextureParameter(GLenum pname, const array<T,N> &v)
{
TextureParameter(pname, &v[0]);
}
void
getTextureParamter(GLenum pname, GLint *v)
{
glGetTextureParameterivEXT(m_name, pname, v);
}
void
getTextureParamter(GLenum pname, GLfloat *v)
{
glGetTextureParameterivEXT(m_name, pname, v);
}
template<unsigned int N, typename T>
array<T,N>
getTextureParamter(enum pname)
{
array<T,N> return_value;
getTextureParamter(pname, &return_value[0]);
return return_value;
}
//etc...
}
//or potentially do NOT make any member functions to
//GLTextureHandler and create functions mirroring
//GL names but such functions taking the type
//GLTextureHandle as the first argument. Which
//is better is the subject of flamewars.
Another nice trick to have would be what many C++ folks do anyways in GL:
template<typename T>
struct opengl_trait
{
typedef T basic_type;
};
//typetraits for basic types
template<>
struct opengl_trait<GLbyte>
{
enum { type=GL_BYTE };
enum { count=1 };
enum { stride=sizeof(signed char) };
typedef GLbyte basic_type;
};
//and so on for basic types...
template<typename T, unsigned int N>
struct opengl_trait< array<T,N> >
{
enum { type=opengl_trait<T>::type };
enum { count=N*opengl_trait<T>::count };
enum { stride=sizeof(array<T,N>) };
typedef typename opengl_trait<T>::basic_type basic_type;
};
which then fits nicely for making tags to feed into a nicer version of glVertexAttribPointer… if your arrays are not interleaved, then the stride you need sizeof(mystruct). Similar template tagging would potentially be nice for glTexImage and it’s friends…
But DSA is not core… I would hazard a guess that DSA will sort of sneak into the spec (as we have DSA for uniforms on programs and for manipulating samplers)… what remains is textures, buffer objects, framebuffer objects and renderbuffers… though I think the use cases of renderbuffers for GL on desktop are non-existant now…
I’d wait for for DSA to sneak into the spec first before embarking on making those header file(s). My 2 cents on the whole thing would be to make types that are just handles to GL objects and not representing the objects themselves (i.e. dtor does not call glDelWhatevers), this way one avoids the ctor/dtor/copy ctor “fun”.
One needs to make sure the API is that it does not “lose” information and nothing goes wrong in using GL calls directly, this is why I’d emphasize the handler thing.