"Daniel Frey" <daniel.frey@[...].de>  wrote in message
news:c21jp0$2i8$1@[...]..

> > 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)?

works.

> Indeed,
> think about a generic algorithm:
> 
> template<typename T> T area(const T& r)
> {
>     return pi * r * r;
> }

also works. At least for float, double, and long double. Do you mean that
your version will
work with physical quantities like meters? If so, could I achieve the same
effect by adding

template< typename T > 
inline T operator*( T l, pi_t )
{ return something; }

?

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

Given the info above, I can't fully understand it.

> >>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.

:-) Ok, but I don't quite see how your approach works for all combinations
without
coding support for them. But I'm willing to wait till you write some docs
about it to find out.

br

Thorsten



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