Re: [boost] units: review

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

On 3/29/07, Matthias Schabel <boost_at_[hidden]> wrote:
> >> 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.
>
> Yes, that would be my preference. We intentionally made the
> constructors require that everything be explicitly specified or
> convertible, so direct construction from a bare value type is
> forbidden - I believe that you agree that this is important. We do
> need to be able to make end-runs somehow for reasons that have been
> elucidated already :
>
> 1) accessing a non-const reference to the quantity data member
>
> this is going to be done through quantity_reinterpret_cast<>
>
> 2) construction of a quantity from a bare value type
>
> this is done through the static member function quantity<>::from_value
> (val)
>
> 3) getting a const value type reference
>
> this is done through the non-mutating value() member function
>
> 4) safe conversion of units from one system to another or from one
> value type to another
>
> this is done through the explicit constructor unless implicit
> conversion has been specifically enabled, either through
> BOOST_UNITS_ALLOW_IMPLICIT_CONVERSIONS or by enabling specific
> implicit conversions.
>
> I don't think we need any of the quantity_cast variants anymore, but
> am happy to be corrected...

I guess I was missing something.  I understand now why you want to get
rid of quantity_cast.  The above sounds good to me.

Zach Laine