Thanks for the clarification... On 1/19/07, Matthias Schabel <boost@schabel-family.org> 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