[boost] Re: Math constants - updated.

From: Deane Yang (deane_yang_at_[hidden])
Date: 2005-05-07 23:09:14

I concur with Tobias on all his points regarding the constants library.

Tobias Schwinger wrote:
> However, macros which can be avoided and do not significantly simplify 
> things _do_ suck (please excuse my straightforwardness), unless you are 
> programming in plain-C (well, they still suck but there often is no 
> better way then ;-) ). They are only acceptable as an interface "#ifndef 
> __cplusplus", IMHO and do not belong in a C++ library.
> 

Using macros to represent constants has no place in a modern C++ 
library, and there is no compelling reason to avoid using functions 
(such as "pi()") to represent the constants. boost is NOT a C library, 
and no other boost library tries to accommodate C programmers. There is 
no reason for the constant library to do so, either.

>> (and also as the functions allowing pi to call a function pi()
>> proposed by Michael Kenniston, even though I am not entirely convinced
>> of their usefulness).
> 

Why is "pi()" any less useful than "pi"?

I also find arguments such as "physicists won't use boost, if they have 
to use the extra parentheses" to be quite unconvincing. Why is that a 
good reason to avoid the parentheses? Certainly, if it's easy to avoid 
the parentheses, it makes us all happier. But if it's not easy, why 
should boost work so hard to accommodate programmers with such dogmatic 
views?

There is a lot in modern C++ programming, including boost, that isn't 
pretty. But if it helps me write better, more reliable, and easier to 
debug code, I'm going to use it. If I have to type an extra pair of 
parentheses to achieve this, I'm going to do it.

> 
> The current state also lacks extensibility. It is not acceptable to rely
> on an external code generator. We have a great preprocessor library for
> jobs like this one. It is desirable to have user-defined constants for 
> arbitrary types, which can be defined from within user code on-the-fly, 
> using a self-contained code generator.
> 

This sounds like a pretty cool idea to me.