Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2004-03-02 09:16:51

Thorsten Ottosen wrote:
> "Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
> news:c21jp0$2i8$
>>>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

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

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.

>>>>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_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at