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

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-03-28 15:07:41

Steven Watanabe wrote:

> The confusion could be on my part.  I was thinking
> that the combo box would allow arbitrary data to
> be associated with the each item.  If this is not
> the case then you need either a map or a switch
> statement regardless of whether the units are compile
> time or runtime.

Well, not arbitrary but some data that is meaningful to the code using 
it that is not displayed to the user.  In my case I was thinking a unit 
type that exists solely for providing conversions.  Not always is that a 
multiplication.  For instance gage pressures adds an extra value on top 
of any conversion when converted from an absolute.  There are also 
cases, that though may be rather questionable, in which two disparate 
dimensions are used for the same kind of thing.  For instance, a user 
can often request that pressures are reported in a "hydrostatic" 
pressure, which is a length.  A hydrostatic unit might contain 
information necessary to do the dimensional conversion to be used in a 
pressure quantity.  For this reason the unit type cannot be a primitive 
if the library is to encompass this use, which I think it should.

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.

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.  How often is one going to use multiple "systems"?  The 
problem of writing expressions in one set of units that may be different 
than the rest of the system is easily accomplished with the use of 
static constants.  I believe that the cases when a static system is 
better are actually very small and it is for that reason that I don't 
believe this library is a good candidate for boost inclusion since the 
object of boost is to provide generic and commonly useful libraries. 
The dimensional analysis part is very generic and useful but the static 
only unit part detracts from this usefulness.