Thorsten Ottosen wrote:
>  "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.

OK, bad example. Your version of pi works, because it doesn't offer a 
conversion to complex<float>  directly. But what about 
boost::rational<T> , RWDecimal<RWMP3Int>, qdouble, etc.? Note that it's 
intended that you don't know all of them by heart :) You rely on special 
properties of std::complex, which are not given in general. Effectively, 
I'd say that you don't support complex, you ignore it. But complex 
supports conversions from/to float, double and long double as required, 
which makes it compatible with your constants. To put it another way: 
You require a specific design of compatible types for your constants. 
This is an unnecessary restriction which limits the use of your 
constants, as there are several types out there that won't match these 
requirements.

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

No, I was talking about the types listed above (rational, RWDecimal, 
...). Currently, unit libraries require their own version. Although the 
decltype/auto-proposal would allow us to write a really cool generic 
version:

template<typename T>  auto area(const T& r) { return pi*r*r; }

:))

>  If so, could I achieve the same
>  effect by adding
>  
>  template< typename T >
>  inline T operator*( T l, pi_t )
>  { return something; }
>  
>  ?

Depends on the ctors of T.

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

Well, all I can say is: It works. The type selection is defered and 
intermediate constants (and expressions with constants) are 
automatically generated by the compiler. As they are themself constants, 
they finally convert to the right type. But I'll try to explain it 
better in the docs. :)

Regards, Daniel

-- 
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@[...].de, web: http://www.aixigo.de



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