RE: [boost] Boost.MathConstants: Review - is this the prototype?

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-04-24 08:54:13

Have I understood this suggestion correctly?
So is there reasonable consensus for this prototype?
Shall I get to work on this?

Paul
Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
mailto:pbristow_at_[hidden]

// math_constants.hpp <<< math constants header file - the interface.
namespace boost
{
  namespace math_constants
  {
    extern const long double pi;
  } //   namespace math_constants
} // namespace boost
//_____________________________________________________________

// math_constants.h <<< the definition file
// Contains macro definitions BOOST_PI, BOOST_E ... as long doubles
#define BOOST_PI  3.14159265358979323846264338327950288L /* pi */
//_______________________________________________________________

 // math_constants.cpp  <<< the implementation
(that might contain dreadful things like unions or assembler!!!)

#include "math_constants.h" // the definitions

namespace boost
{
  namespace math_constants
        {
    extern const long double pi = BOOST_PI; // Uses MACRO long double.
  } //   namespace math_constants
} // namespace boost
//_____________________________________________________________________

// demoExtern_Math_Constants.cpp  <<<  a demo of use, including casting
down.

#include <iostream>
#include <iomanip>
#include <limits>

#include "math_constants.hpp"  // <<< the public interface.

using std::cout;
using std::endl;
using std::setprecision;

int main()
{
        cout << "Test " << __FILE__ << ' ' << __TIMESTAMP__ << endl;

        cout << "pi is " << boost::math_constants::pi << endl;
        using boost::math_constants::pi; // Needed for all constants used.
        // recommended as useful documentation! whereas:
        // using namespace boost::math_constants; // exposes ALL names in
math_constants.
        // that could cause some name collisions!

        cout << setprecision(std::numeric_limits<long double>::digits10 + 2);
        // Ensure all significant digits and two noisy digits are displayed.
        cout << "pi as long double (all significant digits and two noisy) is " <<
pi << endl;

        // double and float obtained by static-casting.
        cout << setprecision(std::numeric_limits<float>::digits10 + 2);
        cout << "pi as float (all significant digits and two noisy) is " <<
static_cast<float>(pi) << endl;

        return 0;
}  // main
//________________________________________________________________________
/*

Output from dmoe

Test demoExternConstants.cpp Tue Apr 24 14:27:14 2001
pi is 3.14159
pi as long double (all significant digits and two noisy) is
3.1415926535897931
pi as float (all significant digits and two noisy) is 3.1415927
Press any key to continue

*/

> -----Original Message-----
> From: austern_at_[hidden] [mailto:austern_at_[hidden]]
> Sent: Thursday, April 19, 2001 8:00 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.MathConstants: Review
>
> >
> > BUT I am VERY keen to use the macro values because of the
> > long and tedious work in altering the generation program
> > to write this file with the constants embedded as above.
> > (And to write a validation program too!)
> > (And it leaves the file of macros useful for C programs -
> > I agree that should be at no extra cost to C++ users).
>
> Why not hide the macros away in a .cxx file somewhere?  I
> don't see any good reason to put the actual numerical
> values in the header.  It's just as good to have something
> like this:
>   // header file
>   namespace whatever {
>     ...
>     extern const double pi;
>     ...
>   }
>
>   // implementation file
>   namespace whatever {
>     const double pi = THE_ACTUAL_NUMERICAL_VALUE;
>   }
>
> If you find it reasonable to have macros, you can hide them
> away in that implementation file where they're out of sight.
>
> This strikes me as a cleaner solution, and I think you'd be
> hard pressed to find a platform where it made a noticable
> difference in performance.  It also has the advantage that,
> on some platforms you could initialize the numerical value
> in tricky ways that wouldn't be appropriate in a header.
> (I'm thinking of awful stuff, like using unions to control
> the exact bitwise representation.)
>