Re: [AD] Problems with gcc 3.1

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


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.



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