From: Alan W. I. <ir...@be...> - 2005-10-02 19:58:59
|
To Andrew (Ross) and Maurice, I am addressing this question mostly to the two of you because you respectively are our C++ and standards experts. On Linux the M_PI constant is defined in /usr/include/math.h as # define M_PI 3.14159265358979323846 /* pi */ A lot of our C++ examples use this constant. Those examples gain access to the constant by #include <cmath> which in turn on Linux includes math.h. However, our other Andrew has just found out that #include <cmath> does not define M_PI on his MinGW/MSYS system. Furthermore, it turns out (see http://www.network-theory.co.uk/docs/gccintro/gccintro_27.html) that the M_PI constant is not an ansi standard. In fact, that web page gives an example where the gcc -Wall -ansi flags choke on M_PI by design to indicate M_PI is not a standard. One brute force way out of this is to insert #ifndef M_PI #define M_PI 3.14159265358979323846 #endif into every C++ example that uses that constant, but perhaps a better option would be to change all the C++ examples to include examples/c++/plc++demos.h, a header which would be designed to handle this issue and all other C++ example-related includes. Note, examples/c/plcdemos.h plays such a role for the C examples. Let me know what you think is the best way to go, and I will be happy to do the required editing. Another related issue is the way we handle the definition of PI (where PI is not even defined in Linux) in c/plcdemos.h. Should I leave the definition of PI in plcdemos.h (in case any of our users are counting on that for their own code), but also define M_PI there as above and change all the C examples from PI to M_PI just to be consistent with the C++ examples? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2005-10-03 08:10:18
|
I believe M_PI (and other maths constants) are not part of the C/C++ standard. (Perhaps they are in C99? I don't know.) I think they are a BSD extension. Every compiler I have encountered has them defined somewhere though. I seem to remember that on Visual C++ you need to define _USE_MATH_DEFINES to get them defined. There may be a trick like this for MinGW/MSYS? I suspect the "#ifndef M_PI" route is the simplest and safest though. Adding a examples/c++/plc++demos.h header file seems a good way to do this. I don't feel strongly either way on whether the constant should be PI or M_PI, but we probably should be consistent with the C version. If there is a consensus then I don't mind doing the necessary legwork. Andrew On Fri, Sep 30, 2005 at 11:12:18AM -0700, Alan Irwin wrote: > To Andrew (Ross) and Maurice, > > I am addressing this question mostly to the two of you because you > respectively are our C++ and standards experts. > > On Linux the M_PI constant is defined in /usr/include/math.h as > > # define M_PI 3.14159265358979323846 /* pi */ > > A lot of our C++ examples use this constant. Those examples gain access to > the constant by #include <cmath> which in turn on Linux includes math.h. > However, our other Andrew has just found out that #include <cmath> does not > define M_PI on his MinGW/MSYS system. Furthermore, it turns out (see > http://www.network-theory.co.uk/docs/gccintro/gccintro_27.html) that the > M_PI constant is not an ansi standard. In fact, that web page gives an > example where the gcc -Wall -ansi flags choke on M_PI by design to indicate > M_PI is not a standard. > > One brute force way out of this is to insert > > #ifndef M_PI > #define M_PI 3.14159265358979323846 > #endif > > into every C++ example that uses that constant, but perhaps a better option > would be to change all the C++ examples to include > examples/c++/plc++demos.h, a header which would be designed to handle this > issue and all other C++ example-related includes. Note, > examples/c/plcdemos.h plays such a role for the C examples. > > Let me know what you think is the best way to go, and I will be happy > to do the required editing. > > Another related issue is the way we handle the definition of PI (where PI is > not even defined in Linux) in c/plcdemos.h. Should I leave the definition of > PI in plcdemos.h (in case any of our users are counting on that for their > own code), but also define M_PI there as above and change all the C examples > from PI to M_PI just to be consistent with the C++ examples? > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the > Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > |
From: <mj...@br...> - 2005-10-03 05:08:08
|
Alan W. Irwin writes: > perhaps a better option > would be to change all the C++ examples to include > examples/c++/plc++demos.h, a header which would be designed to handle this > issue and all other C++ example-related includes. Note, > examples/c/plcdemos.h plays such a role for the C examples. That sounds great. > Another related issue is the way we handle the definition of PI (where PI is > not even defined in Linux) in c/plcdemos.h. Should I leave the definition of > PI in plcdemos.h (in case any of our users are counting on that for their > own code), but also define M_PI there as above and change all the C examples > from PI to M_PI just to be consistent with the C++ examples? Maybe we need a PL_PI? :) I don't feel strongly either way. -- Maurice LeBrun mj...@br... |
From: Alan W. I. <ir...@be...> - 2005-10-07 19:18:36
|
On 2005-10-03 09:10+0100 Andrew Ross wrote: > I suspect the "#ifndef M_PI" route is the simplest and safest though. > Adding a examples/c++/plc++demos.h header file seems a good way to do > this. I don't feel strongly either way on whether the constant should be > PI or M_PI, but we probably should be consistent with the C version. I have just committed plc++demos.h and done all the necessary Makefile.am and c++ examples changes to use it. Also, I have made appropriate changes to the c examples so that M_PI is now #defined and used consistently for all the c and c++ examples. I see no build problems with make check in the build tree or make in the installed examples tree. Also, the c++ and c postscript results look good and agree exactly (except for date). Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |