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