Re: [AD] Proposal for new Allegro interface

[Javier Gonzalez <xaviergonz@xxxxxxxxxx>]

The only possible solution i see here is making 2 libraries
say alleg and alleg4.

make by default would build alleg4
and
make OLDALLEGRO=1 would build alleg

The dlls (or other kind of shared libs) would be for example
all3938.dll for old one
and
all43938.dll for new ones

Probably using those macros you talk below could be possible...

With something like

#ifdef OLDALLEGRO
  #define AL_PREFIXED_FUNC(type, name, args)  _AL_DLL type __cdecl name args
#else
  #define AL_PREFIXED_FUNC(type, name, args)   _AL_DLL type __cdecl
al_##name args
#endif

and so for AL_VAR, AL_ARRAY, AL_METOD, AL_FUNCPTR and so on


Oh well, one of my usual stupid ideas =)


----- Original Message -----
From: "Sven Sandberg" <svsa1977@xxxxxxxxxx>
To: "Allegro Developer" <conductors@xxxxxxxxxx>
Sent: Thursday, September 13, 2001 12:32 AM
Subject: Re: [AD] Proposal for new Allegro interface


> Laurence Withers wrote:
> >  - increases complexity slightly, both when maintaining code and
> >    when adding new stuff (because you need to think of two function
> >    names :-P ).
>
> There's hardly any reason to add non-prefixed versions of new
> identifiers, so I don't think this is a problem.
>
> I agree that if something should be done, then what you suggest is very
> close to it. I even think that making palettes be 8 bit will work
> smoothly: As long as all old-style functions continue to assume 6-bit
> palettes, there's no harm done if the prefixed functions use 8-bit
> palettes. There are four `extern PALETTE' variables, but those don't
> seem to be any problem either (black_palette isn't even different in 8
> bits, desktop_palette and default_palette are not read by the library
> anyway, and I don't think fli_palette is either).
>
> I have a couple of additions to the "Minus" section though:
>
>  - What about variables? I think the only way to create aliases for
> these is with #defines. And this will be a problem for C++ programs
> which have member variables called e.g. `screen', `key' or `font', if
> one file that uses the class #includes <allegro.h> and another doesn't.
> This happens e.g. if the class is defined in some library. IMHO `key'
> and `font' are some of the worst namespace polluters so it would be a
> pity not to get rid of them.
>
> A possible solution would be to make `key' be the actual name of the
> variable and `al_key' the macro (because `al_key' is a lot less likely
> to appear in people's code). OTOH, this only solves the cosmetic problem
> that only 99% of the identifiers would be available in prefixed form. It
> still doesn't allow you to define your own variable named `key'. It also
> makes this limitation a great deal more subtle.
>
>  - Another problem is that some compilers (at least watcom) don't remove
> unused static functions, so that each object file will contain tons of
> such. Moreover, each such static function will contain a dependency to
> some part of Allegro (and conversely: each and every function in Allegro
> will be used in one of those functions), so that literally _all_ of
> Allegro will be linked in on those platforms. And it will require you to
> link with Allegro, which wasn't strictly needed before if you only used
> e.g. inline math functions.
>
> Luckily gcc and msvc are smart enough to remove unused static functions
> and maybe we don't need backwards compatibility (i.e. aliases) for other
> platforms? AFAICS except for watcom they have only existed in fairly
> recent wips, and who uses watcom anyway? :-) No, I don't think this is a
> good solution.
>
> > Please send your thoughts. If generally positive, and nobody raises
> > any unsolvable technical issues, I'll write a patch and submit it for
> > examination.
>
> To the person who implements this, if it ever happens: it can be done
> fairly automatically by modifying the AL_FUNC() & co macros, e.g.:
>
>    #define AL_PREFIX_FUNC(return_type, func, args, call_args) \
>       return_type al_##func args; \
>       static INLINE return_type func args \
>       { \
>          al_##func call_args; \
>       }
> [...]
>    AL_PREFIX_FUNC(void, floodfill, (BITMAP *bmp, int x, int y, int c),
>                   (bmp, x, y, c));
>
> This ought to cut down the work a lot (though of course we don't want
> `al_allegro_init()' so not all functions can be handled this way).
>
> But I would personally vote "no" unless someone comes up with good
> solutions to the problems I mentioned.
>
> Sven
>