Re: Boost.MathConstants: Review

From: Ed Brey (brey_at_[hidden])
Date: 2001-04-19 16:13:47

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> Hmm, in trying to weigh the relative importances of things, I think 
that
> accuracy comes out way ahead of the ability to do some kind of 
compile-time
> deduction on floating constants which have been converted to integer
> expressions. Can you give an argument for the utility of the latter?
> 
> From: "Ed Brey" <brey_at_a...>
> >
> > int main() {return int(boost::math::constants<float>::pi());}
> >
> > causes VC6 to the same code as a simple "return 3;"  In general,
> > having the constant in the same translation unit is useful any 
time
> > the compiler can figure out something at compile time, like
> > c::e() / 16.

I guess I wasn't very clear.  I agree that my first example is a rare 
case and not worth much concideration.  I only mentioned because it 
was the case in which I actually looked at the generated assembly.

My second example was meant to be real-world.  The "16" should have 
been "16." (or you can say that I forgot my period).  As a more 
concrete example, suppose someone wants to take the volume of a 
sphere, and writes  4./3. * c::pi() * pow(r, 3).  The compiler can 
work the 4./3. * c::pi() into a single constant at compile time.  It 
won't be as accurate as if the one used an arbitrary-precision 
calculator to generate the decimal form for this, but in most cases 
that kind of precision isn't needed.  The user is perfectly happy to 
have spent minimal effort and ended up with a perfectly good enough 
compile-time-determined value without getting out his textbook and 
typing in 3.1415... by himself.

The part I'm not understanding is what value is there to _not_ having 
the constants in the header, given that a header with built-in values 
can be easily generated?