Boost logo

Boost :

From: Matt Austern (austern_at_[hidden])
Date: 2001-04-19 14:00:23


"Paul A. Bristow" wrote:
>
> > -----Original Message-----
> > From: Ed Brey [mailto:brey_at_[hidden]]
> > Sent: Thursday, April 19, 2001 4:19 PM
> > To: boost_at_[hidden]
> > Subject: [boost] Boost.MathConstants: Review
> >
> I am content to provide an .hpp file of this form
>
> > namespace boost {
> > namespace math {
> > template<typename T>
> > struct constants {
> > static T pi() {return T(3.1415...L);}
> > };
> > }
> > }
> >
> > where a typical user experience would be documented as this:
> >
> > typedef boost::math::constants<float> c;
> > std::cout << "Baseball and apple " << c::pi();
>
> as suggested (but alas not suggested in previous discussions!)
>
> 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.)

                        --Matt


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk