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

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-01-19 15:58:04

Hello Ben,

[snip]

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

Sorry to interleave your discussion.

I'd add (2.5) quantity_cast to translate compatible quantities, e.g.
meters <-> miles.

I'm also not quite happy with having three casts instead of one. IMO,
this would complicate the library usage with almost nothing in return.
Although I may imagine some searching profit of having
quantity_static_cast, it doesn't worth it.

And as for reinterpret_quantity_cast, I can really see no use for it.
The value of the quantity may be obtained via a simple method, like
"get" or "value" and the opposite conversion may be done with explicit
constructor with applying a dimension. I'm not quite sure I followed
you in "would be useful for arrays", so I may be missing something.

And after all reinterpret_quantity_cast may need a better name if it
is to be implemented. The difference in word order in
quantity_static_cast and reinterpret_quantity_cast is confusing and
I feel getting older while typing "reinterpret_quantity_cast". :)

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]