[boost] Re: [math constants] a new approach (perhaps)

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2004-03-02 04:22:39

Thorsten Ottosen wrote:
> "Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
> news:c1vlqp$90l$1_at_sea.gmane.org...
> Thorsten Ottosen wrote:
> [snip]
> 
>>It depends on what exactly you tried. The basic problem is, that T(pi)
>>tries to call a ctor for T, but std::complex has several candidates
>>available. std::complex<double>(std::complex<double>) and
>>std::complex<double>(double) might conflict here, except you don't
>>provide conversion to std::complex<double> for your constants. But you
>>cannot assume this for other UDT. What happens if a UDT has ctors taking
>>float, double and long-double? You can't use your constants any more,
>>even a new conversion to the type directly won't help.
> 
> Sorry, but I don't get this.
> 
> complex<float> z = float( pi );
> 
> should work just fine.

Sure, but what about complex<float> z = complex<float>(pi)? Indeed, 
think about a generic algorithm:

template<typename T> T area(const T& r)
{
    return pi * r * r;
}

(or even T(pi)*r*r). You need constants that work well for all types 
with no special treatment of some types.

>>Why
>>shouldn't this scale to pi*pi*t? Or sqrt(pi)*t. The first non-constant
>>should select the type, no matter how the constants are used before.
> 
> Yeah, I could let pi * pi return a two_pi object.

No. OK, "yes" for this example, but "no" in general. You cannot predict 
all combinations the user could write. Simply providing all possible 
combinations is ridiculous overhead which doesn't scale well. My 
constant library works for any combination, whether predefined (that is, 
there is a real constant pi_square (ha, you got fooled by your own names 
- the naming dilemma! :) ) ) or not.

>>>>From your example file:
>>>
>>>std::cout << pi.get< float >() << std::endl;
>>>
>>>which is float( pi ) spelt more elaborate.
>>
>>As mentioned, this is a very important thing to note that .get<T> is
>>free to return something else than T!
> 
> maybe not the best way to spell the function then?

I'm open to suggestions. I don't like .get<T>() very much myself, but I 
can't imagine any better solution.

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial solutions & technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de