[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