[GRASS5] r.flow: strange compile error M_PI
Brad Douglas
rez at touchofmadness.com
Tue Jun 28 12:43:52 EDT 2005
On Tue, 2005-06-28 at 17:20 +0100, Paul Kelly wrote:
> On Tue, 28 Jun 2005, Brad Douglas wrote:
>
> > On Tue, 2005-06-28 at 23:38 +1200, Hamish wrote:
> >>> Personally, I would just conditionalise the local definitions, e.g.:
> >>>
> >>> #ifndef M_PI
> >>> #define M_PI 3.14159265358979323846
> >>> #endif
> >>
> >> why not go straight to the long?
> >>
> >> 3.1415926535897932384626433832795029
> >> or
> >> 3.1415926535897932384626433832795029L
> >>
> >> (but don't call that M_PI)
> >
> > That should be called M_PIl.
> >
> > I like the idea of adding these macros to gis.h, if not sorting it out
> > with autoconf (still my favored method).
>
> I think the logic with autoconf should be to use it if it simplifies
> things; in this case it appears to make it more complicated so the simple
> solution is better. Unless it is possibel for the definition of M_PI in math.h
> to be somehow "better" than our own version. It actually probably makes the
> output of GRASS more consistent cross-platform if every module is always
> using the same definition (in gis.h), rather than perhaps that or perhaps
> the one in math.h, depending on compiler options and platform-specific
> stuff.
Doing what you suggest means editing a lot of source that uses M_PI,
because we'd have to give it a new name (like G_PI) to avoid conflicts.
No sense arguing over semantics of a non-problem. I don't see the
definition of PI changing anytime in the future (unless "intelligent
design" is correct and science doesn't exist ;).
Just put it in gis.h with a little comment saying it isn't defined in
ANSI-C and be done with it.
--
Brad Douglas <rez at touchofmadness.com>
More information about the grass-dev
mailing list