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.)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
