Re: [AD] AL_ prefix clashes with OpenAL

[Chris Robinson <chris.kcat@xxxxxxxxxx>]

On Saturday 07 July 2007 07:45:41 am Matthew Leverton wrote:
> On 7/7/07, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> > One point we are currently discussing in the meeting is the clash of the
> > AL_ prefix for Allegro 5 with OpenAL.
>
> I really like al_ for functions, so to me the least evil option is
> al_* and ALLEGRO_*.  However, I dislike ALLEGRO_ for structs, but I
> could live with it.

Another idea that just came up with on IRC would be to use a struct of 
function pointers for the "exported" Allegro functions. The idea would be to 
have a struct that contains all the functions Allegro can export, then have 
an inline function load them in the user program.

Internally, the functions could be defined and exported normally, eg: as 
allegro_blit or whatever. It requires no changes at all to how the functions 
are made in the lib. A function inlined with the user's program would then 
get the address to allegro_blit and place it into a defined struct's function 
pointer. It could look something like this:

/* allegro/allegro.h */
struct ALLEGRO_FUNCS {
#include <allegro/system_exports.h>
#include <allegro/gfx_exports.h>
...
};
#define DECLARE_ALLEGRO_NAMESPACE(x) ALLEGRO_FUNCS x
#define DEFINE_ALLEGRO_NAMESPACE(x) extern ALLEGRO_FUNCS x

static inline int allegro_load_funcs(ALLEGRO *al, void *lib_handle)
{
    al->version = GetFunc(lib_handle, "allegro_version");
    al->init = GetFunc(lib_handle, "allegro_init");
    al->init_keyboard = GetFunc(lib_handle, "allegro_init_keyboard");
    al->init_sound = GetFunc(lib_handle, "allegro_init_sound");
    al->blit = GetFunc(lib_handle, "allegro_blit");
    ...
    return 0;
error:
    return 1;
}

/* user code would look something like this */
#include <allegro/allegro.h>
DECLARE_ALLEGRO_NAMESPACE(al);

int main()
{
    if(allegro_load_funcs(&al, NULL) != 0)
        oops();

    al.init(ALLEGRO_VERSION);
    al.init_keyboard();
    al.init_sound();
    ...
    if(al.get_error() != ALLEGRO_NO_ERROR)
        oops();
}


The GetFunc calls could be segmented into subsystem-specific load functions, 
also declared static inline in their respective headers, so as not to polute 
allegro.h with having to "know" everything.

ABI incompatibility would be a non-issue since the Allegro lib never touches 
the ALLEGRO_FUNCS struct, thus it can change however often it needs in any 
way it needs. The namespace would be named by the user, so they can use 
allegro, al, a, whatever.

As well, it makes special-casing static linking completely unnecessary. The 
functions wouldn't need to be dllimport'd by the headers, and GetProcAddress 
and such can pull the functions right from the executable. Also, it would 
work *with* programs that want to load the allegro dll at run time, instead 
against them by forcing the program to create the function pointers and 
manually load them and everything. Allegro does it all for you.

Enums can also optionally be placed into the struct, so instead of 
ALLEGRO_SOME_ENUM, it could be al.SOME_ENUM. Granted that doesn't look very 
pretty, but it's only an idea, and can work without harming anything (if 
someone didn't want to, the program would not have to use it). Structs would 
still need to use ALLEGRO_ or whatever (unless you can do al.BITMAP *bmp; or 
something, somehow).