Re: [AD] Problems with gcc 3.1

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]



On Thu, 25 Oct 2001, Peter Wang wrote:

> On 24 Oct 2001, salvador <salvador@xxxxxxxxxx> wrote:
> >
> > > (b) On the other hand, the conflicts are kind of rare.  So we should
> > > rename the f* functions to fix*, but provide aliases by default.  If
> > > the user really needs to use the libc/m fsqrt (etc) instead of
> > > Allegro's fsqrt (etc), he can switch off the aliases.  The aliases
> > > would be static inline functions, so even if you use Allegro's fsqrt
> > > in one module, you can still use the system's fsqrt in another.  If
> > > done right, there shouldn't be any warnings or anything.
> ...
> > If you go for (b) just add some mechanism to automagically disable the aliases.
> > Example: during configure mechanism detect if aliases collide, if that's the case
> > disable aliases
>
> This is what I had in mind.  Say math.h declares:
>
> float fsqrt(float);
>
> Then in the Allegro headers:
>
> fixed fixsqrt(fixed x);
>
> #ifndef ALLEGRO_NO_FIX_ALIASES
>    #ifdef ALLEGRO_MATH_FUNCTIONS_CONFLICT
>       #define fsqrt(x) (__get_out_of_the_way__fsqrt(x))
>       #include <math.h>
>       #undef fsqrt
>    #endif
>    static inline fixed fsqrt(fixed x) { return fixsqrt(x); }
> #endif
>
> What does everyone think of it?  Will it work?  It does mean the user
> will have to include allegro.h before math.h on systems that have
> conflicts, but that's not _hopelessly_ bad.

Or he could write

#define ALLEGRO_INCLUDE_MATH_H
#include <allegro.h>

and voila, it works (right now only for SGI IRIX). It's basically the same
as your solution.

Have a nice day.

Stepan Roh



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/