Re: [boost] [Review] Quantitative units - compile time vs runtime

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-03-28 15:27:55

AMDG

Noah Roberts <roberts.noah <at> gmail.com> writes:

> <snip>
> 
> In my case I was thinking a unit 
> type that exists solely for providing conversions.  Not always is that a 
> multiplication.
>
> <snip>

Ok.  Good point.  You can use type erasure to get this effect
and be able to use the static conversions at runtime.

template<class Quantity, class InputQuantity>
Quantity quantity_converter(const typename Quantity::value_type& v) {
    return(quantity_cast<Quantity>(InputQuantity::from_value(v)));
}

> Also, your idea has problems when you account for rounding.  Rounding is 
> often done before you display data to a user.  In cases when this data 
> can come from a calculation or from the user it is hard to decide when 
> to round and when not.  If you apply rounding and conversions on both 
> input and output and add rounding into the mix you can have a user 
> entered value that gets reported back to the user as something else. 
> This is not acceptable in many cases.

I may be wrong, but in order to avoid any excess loss
of precision you have to store a set of all the base
units and track the actual unit at runtime involving
a merge with every multiplyor divide.  This kind of
overhead is not always acceptable.

> At any rate, there are ways to solve the whole thing regardless.  The 
> question is, what is the use of a library that only does static 
> conversions.

As has been stated many times conversions are not
the primary point of the library.

> How often is one going to use multiple "systems"?

Hopefully not very often.

In Christ,
Steven Watanabe