Re: [boost] mcs::units informal review request

From: Ben FrantzDale (benfrantzdale_at_[hidden])
Date: 2007-01-19 14:21:39

Thanks for the clarification...

On 1/19/07, Matthias Schabel <boost_at_[hidden]> wrote:
>
> >> 3) implemented quantity_cast for three cases (see
> >> unit_example_5.cpp) :
> >>         a) construction of quantities from raw value types
> >>         b) conversion of value_types
> >>         c) conversion of unit systems
>
> > It isn't clear to me what the semantics of these three are. I'd
>
> Semantics are :
>
> a) construct quantity from value_type
> double x = 10.0;
> quantity<length,double> q = quantity_cast< quantity<length,double> >(x);
>
> b) change value_type
> quantity<length,double> y = 10.0*meters;
> quantity<length,std::complex<double> > q = quantity_cast<
> std::complex<double> >(y);
>
> c) change unit system
> quantity<SI::length> z = 10.0*meters;
> quantity<CGS::length> q = quantity_cast<CGS::length>(z);
>
> > quantity_cast should be a dimensionally safe operation. Is that the
> > semantics you have in mind?
>
> I was thinking the opposite - i was under the impression that
> explicit casting
> usually indicates something that's potentially _unsafe_...

With the exception of (a), these are safe(ish) operations. For (c), the
operation is very dimensionally safe. (I'd argue it should be implicit, but
I'm fine with being more strict for now.) For (b) the semantics really are
the same as a static_cast since the only thing changing is the type, so it's
dimensionally safe even if it's type-dangerous. But (a) I worry about. For
something like that I'd rather see another name for the cast since it is a
potential hole in the unit system – something like
reinterpret_quantity_cast. (There's always reinterpret_cast for doing things
that are really unsafe.)

I picture a few reasonable casts:
(0) Casting equivalent units (meters -> feet). This is very very safe and so
should have its own cast (if it has a cast at all). (Perhaps quantity could
just have an explicit constructor so that static_cast works? Then a
precompiler definition could toggle that "explicit" for those who want this
to be implicit.)
(1) static_casting enclosed types (perhaps "quantity_static_cast"?)
(2) Adding explicit dimensions to something that's got only general units.
That is, quantity<length> -> quantity<meters> but not quantity<length> ->
quantity<time>. This seems reasonably safe. (Perhaps that would get
quantity_cast?)
(2) a. Casting doubles to quantity<D>s.
    b. Casting back to the enclosed type for use in other libraries.
    These are both potentially dangerous, but not too bad as long as it
allows only conversions to and from enclosed types (e.g., quantity<length>
-> double and double -> quantity<time>) but disallows quantity-to-quantity
conversion (e.g., quantity<length> -> quantity<time>). (Perhaps
reinterpret_quantity_cast?)

So what I'm proposing is three new casts:
(1) quantity_static_cast to static_cast the enclosed type. (This would show
up in searches for static_cast.)
(2) quantity_cast to add or remove quantity information (length <-> meters).
(3) reinterpret_quantity_cast to go to and from, e.g., doubles. (This would
also show up in searches for quantity_cast and for reinterpret_.) This
wouldn't be necessary for scalars since division and multiplication would
work, but would be useful for arrays.

—Ben