"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:c1vlqp$90l$1@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.
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.
- Doesn't work well with unit libraries AFAICS (again not scaling well) how?
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?
std::cout << sqrt( sqrt( two + pi ) ) + d << std::endl;
will everything left of d be a constant? If so, what would the point be?
Basically, it's not a single constant. The constants are both casts to d's type, added and sent through sqrt two times. But you can - if you want to - make it a single, fast constant if you think it's worth the effort for your program.
ok. I can see that my approach might not scale too well. br Thorsten