RE: [AD] namespace collision

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Title: RE: [AD] namespace collision

Peter Wang writes:
> > The only concern I have is whether other compilers support the idea
> > of "extern inline", whether using those exact keywords or others.
>
> Of course, we can fallback to "static inline" on compilers that
> don't support it.  So that's not a problem.
>
> If the compiler doesn't support "inline" (MPW?), then we're in big
> trouble.

"extern inline" only works with GCC. "static inline" should be ok for
anything that supports inline functions, but not all compilers do:
Watcom (at least v10) doesn't for C code, and I doubt any non-gcc Unix
compilers (Sun, SGI, etc) will know about them either. It is also quite
fiddly to get inlines to work in debug builds, where the compiler won't
actually inline anything.

On the one hand it's hard to care too much about compilers too crap to
support inlines, but on the other hand people using those compilers
probably do care a bit more :-)

On the third hand, Allegro already has a mechanism to provide reliable
inlines on all compilers: the AL_INLINE macro in the headers, coupled
with src/inline.c. This could be extended to provide API wrappers,
although the need for a separately compiled copy of the functions
(produced by inline.c) means the wrappers do need to be linked into
the lib, rather than purely expanded out in a header. That shouldn't
cause any linker problems as long as the object containing wrappers
is kept totally isolated from everything else, though, as the linker
just won't include it unless someone actually uses these wrapped
functions.

Inlines still can't fix all the global var names, though, so #defines
would still be needed as part of the wrapper.

        Shawn.