"Daniel Frey" <daniel.frey@[...].de>  wrote in message
news:c1vlqp$90l$1@[...]..
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost