[boost] Re: RE: Math Constants Formal Review - recap & summary

From: Ed Brey (brey_at_[hidden])
Date: 2003-06-09 08:56:55

Paul A Bristow wrote:
> A Mini-recapitulation of the _long_ saga so far:
> 
> 7  There are dozens of constants that some users rate 'essential'.
> Splitting into several #include files still risks violating the
> "don't pay for what you don't use" principle.

> 10 There is evidence that some compilers can generate better code
> from functions like "double pi() { return 3.1459;}"
> but that this implies writing pi() instead of plain "long double pi".
> So the ()s remain a major issue.

These two points are based on observations that compilers don't optimally handle constants defined like this:

double const d1 = 1.2;

It would be useful to record exactly which compilers have which troubles, so that as compilers improve, constraints can be dropped.

For example, VC 7.1 discards d1 if it is not referenced, so there is no issue with paying for what you don't use when using that method on that compiler.  It would be useful to know what compilers do retain unused constants.

The FAQ entry "Why are functions like double pi() which return constants provided?" has a start to the idea of documenting specific compiler limitations.  I'd recommend adding this elaboration on VC 7 (others can help with other compilers):

- Static constants are referenced via a pointer, which leads to smaller code if the constant is used more than once, but often to slower code.

(I would take out the blurb about MSVC 7 Standard edition.  Does anyone who needs to professional-grade execution speed really buy the standard, rather than professional edition?  The professional edition inlines properly according to the standard-specified "inline" keyword hint.)