Re: [boost] units: review

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2007-03-29 15:28:49

On 3/29/07, Matthias Schabel <boost_at_[hidden]> wrote:
> > While quantity_reinterpret_cast may not be perfectly analogous to
> > reinterpret_cast, it represents the reinterpretation of a raw number
> > as being of a different type, and so I think it's a pretty good name.
> > Just as importantly, I can't think of anything better.  Do you have
> > any other ideas?  quantity_unsafe_cast? quantity_arbitrary_cast? :)
>
> Sorry, I think I muddied the waters here - I agree that
> quantity_reinterpret_cast should be reserved for those cases where
> access to the raw data is necessary. I was just saying that we can
> write things like
>
> quantity<SI::length,double>     q;
> quantity<SI::length,int>                r;
> quantity<CGS::length,double> s;
> quantity<CGS::length,int>               t;
>
> q = quantity<SI::length,double>(r);
> q = quantity<SI::length,double>(s);
> q = quantity<SI::length,double>(t);
>
> already, so the only non-degenerate use case of quantity_cast is to
> take a raw value and return a quantity:
>
> q = quantity_cast< quantity<SI::length,double> >(1.5);

Maybe I'm missing something here, but why shouldn't this last cast be
done using a constructor instead:

q = quantity<SI::length,double>(1.5*meter);

This way, the set of library capabilities is no different, but the
resulting code is more explicit, and quantity_cast cannot be used in a
type-unsafe way.  Further, it's name suggests that quantity_cast only
casts between quantities, not between underlying values and quantites.
 Taking a raw value and constructing a quantity from it should be the
sole purview of the quantity constructor.

Zach Laine