[boost] Re: Math constants - updated.

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-05-08 15:50:16

Andy Little wrote:
> 
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote
> 
>> Andy Little wrote:
>> Besides getting rid of the empty parentheses, there are the following 
>> disadvantages:
> 
>   ^^^
> I Assume you mean In spite of ?
> 

Yes I do, thanks for the correction.

>> - modularity/extensibility (once constants<T> is defined you can't add 
>> constants to it)
> 

John's post in this thread explains this point in more detail.

> 
> In practise you can.  constants struct 's members are really just global 
> constants. Your compiler wont know the difference, because it only 
> instantiates what you ask for, add a new type and it wont know its there 
> till you use it, and will then assume its always been there.  However 
> not conforming I guess. A derivation  for the newer constants would be 
> conforming.
> 
> template <typename T>
> struct constants2 : constants<T>{
>    static T const & andys_constant;
> }
> template <typename T>
> T const & constants2<T>::andys_constant = T(2005);
> 
> typedef  std::math::constants2<double> math;
> 2 * math::pi * r ;
> 

Hmmm.... This seems most clumsy to me. A matter of personal taste, perhaps.

>> - portability (the code above won't compile with BCC)
> 
> 
> Whats the error. AFAIK its correct C++  is it not ?  If its correct C++ 
> then I think this is not a strong argument.
> 

Probably - but it's not the only one.

>> - there is no way to pass constants as a type template argument.
> 
> ( IOW  use a function ..? )

No. A class somehow like this:

        template<typename T> struct name;

        template<> struct name<TYPE>
        {
                operator TYPE() const { return ... };
                TYPE operator() () const { return ... };
        };
        //...

> Well .. is that an essential ?..Do you have a use case demonstrating 
> this need? 

The interface of std::generate is more generic than the one of std::fill.
Representing constants as functors we don't need to write less flexible 
interfaces like the one of std::fill (which can be seen as a special case of 
std::generate, provided for convenience).

> AFAIK constants are always pretty specific to their own 
> particularly algorithms.

I don't think e.g. 'zero' or 'one' are.

> Whatever ... I still like  std::math::constants<T>::pi   much better 
> than std::pi<T>()     :-)

Any pro arguments ;-) ?

It's common practice to call getter member functions, so what is wrong with 
"global getter functors" to encapsulate constants ?

It's even formally correct math, as you can define functions like this:

        f(a,b,c) = d = const

I also feel some sympathy for the idea of allowing any number of (dummy) 
arguments for operator() because it plugs nicely into generic functional code.

Example:

        template< [...], typename AngleFunction>
        struct hinge
        {
                AngleFunction f;
                [...]
                        f(time)
                [...]
        };

        typedef hinge< [...], constants::pi > const_hinge_180;

Regards,

Tobias