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
> Thorsten Ottosen wrote:
>>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.
>>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.
-- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 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