Strange Issues regarding aliases

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 14 June 2016 at 17:37:40 UTC, Joerg Joergonson wrote:
> On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson 
> wrote:
>>> This is how derelict does it, I simply moved them in to the 
>>> class for simplicity.
>>
>> I mean glad: http://glad.dav1d.de/
>
> It seems that a loader is required for some reason and that 
> possibly could be one or both of the problems.

Yes, Derelict and glad both work this way. A loader is required 
because you are using function pointers, which means you need the 
memory addresses of the functions in the library, which are only 
known at runtime when the library is loaded into memory. There's 
no way around it. You are doing manually what the system loader 
does when you declare a normal function and link with an import 
library (on Windows) or directly with a dynamic library (on Posix 
systems).

You should be declaring your functions something like this:

// Most functions in C libraries should be extern(C), but OpenGL 
needs to
// be extern(Windows) on Windows and extern(C) everywhere else. 
extern(System)
// handles that for you. Making them nothrow and @nogc is very 
handy for D
// code that needs those attributes.
extern(System) @nogc nothrow {
     alias aClear = void function(int);
}

struct GL {
    aClear clear;
}

void loadFuncs(ref GL gl) {
     // This is system specific. You can see the possibilities in
     // the module derelict.opengl3.gl3
     version(Windows) ennum libName = "OpenGL32.dll"

     // loadSharedLibrary should wrap OS-specific 
LoadLibrary/dlopen
     auto lib = loadSharedLibrary(libName);

     // loadFunc should wrap OS-specific GetProcAdress/dlsysm
     gl.clear = cast(aClear)lib.loadFunc("glClear");
}