
Boost : 
From: Daniel Frey (daniel.frey_at_[hidden])
Date: 20040302 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 longdouble? 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 nonconstant
>>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ßRaheStraße 15, 52072 Aachen, Germany fon: +49 (0)241 93673742, fax: +49 (0)241 93673799 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk