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

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-19 14:50:51

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

The rationale for preventing implicit conversions is that much of the  
point
of this library is to provide dimensional analysis with zero runtime  
overhead -
as soon as you allow implicit unit conversions, that's out the  
window. In
addition, you run the risk of losing precision if implicit conversion  
is allowed
between unit systems having significantly different scales (say  
astronomical
and high energy physics units). Even implicit value_type conversion  
poses
a similar problem, but at least there the precedent is already  
established with
built-in value_types... The performance issue is a big one because  
one of
the major anticipated use areas for this sort of library is numerical  
computing
where performance is critical and no overhead is acceptable at  
runtime...

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

Is it possible to overload the system reinterpret_cast, or is it not  
really a
library function? If it was, that might be an option, too...

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

Actually this is how it is currently implemented. You can do explicit  
unit system
conversions via constructor, and there is a precompiler option:

#define MCS_UNITS_ENABLE_IMPLICIT_CONVERSIONS

for enabling implicit conversions. So maybe the value_type  
quantity_cast is
redundant... Let's see what others have to say on the topic...

> (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?)

As now implemented, if you want to have generic code that works for  
units of
any system, you need to template it on unit system like this
(from unit_example_4.cpp):

/// the physical definition of work - computed for an arbitrary unit  
system
template<class System,class Y>
quantity<unit<System,energy_type>,Y>
work(quantity<unit<System,force_type>,Y> F,
      quantity<unit<System,length_type>,Y> dx)
{
     return F*dx;
}

>     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?)

This is supported through the value() member function in quantity,  
too...

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

I think we basically agree on the desirable functionality; I'm not  
particularly
wedded to the specific syntax I've chosen now, but would like to get  
more
input from others before making changes...

Thanks for the comments,

Matthias