interfacing C bitfield structs

[Wolfgang Draxinger]

Lucas Goss wrote:

> But if you don't want to 
> take that approach (the dynamic loading), Anders has sdl
> bindings here: http://www.algonet.se/~afb/d/

Nice, eventually I even use his bindings.

Eventually I put my GLEW bindings over his.

My GLEW bindings are up and running, without multicontext support
though. I still must write a small script the generates the D
template functions for this.

If compiled with multitexture supprort GLEW expects the user to
supply a function GLEWContext *glewGetContext(). This is used in
macros like

#define glActiveTextureUnitARB
GLEW_GET_FUN(__glewActiveTextureUnitARB)

And GLEW_GET_FUN is a macro

#ifdef GLEW_MX
#define GLEW_GET_FUN(x) glewGetContext()->x
#else
#define GLEW_GET_FUN(x) x
#endif

So far the only way I know to bring this to D is to do something
like this

version(GLEW_MX)
{
template glActiveTextureUnitARB(unit){ GLvoid
glActiveTextureUnitARB(unit) { return
__glewActiveTextureUnitARB(unit); } }
}
else
{
alias __glewActiveTextureUnitARB glActiveTextureUnitARB;
}

I'm using templates since using normal functions would eventually
be compiled not as inline, which is preferred.

This got me to an idea for a new D feature, that would allow to
use aliases as a replacement for macros, if I could have written

template glActiveTextureUnitARB(...) function { return
glewGetContext().__glewActiveTextureUnitARB(...) ; }

It would be much more readable. I mean, that by adding the
keyword 'function' after the template definition you don't have
to repeat the template name to make it a function template and
the ellipsis '...' as a placeholder for an arbitrary long
parameter list, eventually supporting some scheme to extract a
certain parameter.

But so I have to extract the parameter list and the return type
from the extension functions definition and generate template
worms for it.

-- 
Wolfgang Draxinger