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

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-02-13 02:20:09

>>> quantity<SI::length> cent(cents);
>>> cent = 2 * meters;
>>> assert(cent.value() == 200);
>
> saying so doesn't exactly do much to counter.  I think it pretty  
> obvious
> what it 'means'.  2 meters get assigned to a value in
> centimeters...should come out with the value 200...you're syntax would
> have to be expanded.

Lengths in the SI unit system are not measured in centimeters, so the
first line here doesn't make sense. If you want this behavior, you
need to enable implicit unit conversions by defining

#define MCS_UNITS_ENABLE_IMPLICIT_CONVERSIONS

Then this works how you seem to want it to:

quantity<CGS::length>	cent(1*centimeter);

cent = 2*meters;

will give cent.value() == 200.

> It's a moot point.  No, it isn't possible within your framework...at
> least not easy.  But as you're set in your way and not really open to
> this anyway...and since I'm in the minority it seems...it's going  
> to be
> what it's going to be.  I'm not going to struggle against the wind on
> this one.

I'm not trying to discourage you from having your voice heard. This  
library
has undergone a number of dramatic changes in response to various
suggestions and requests. If your concept is something that appears to
be feasible and sufficiently interesting to a broad spectrum of users, I
would be happy to consider it. However, I am having a hard time really
understanding specifically what you want to do. My best current guess
is that you want a quantity class that is capable of holding a unit  
having
a specified dimension but with runtime-varying unit system. That is

quantity<abstract::length,Y>

would represent a length in any unit system you wanted, where the
unit system can change dynamically. But, to get back to Steven's  
question,
what would this support that the existing library with explicit (and  
possibly
implicit) conversions doesn't already?

For user input, you can just do this:

quantity<SI::length> getInput(const unit_enum& input_unit,double val)
{
        typedef quantity<SI::length>	return_type;

        switch (input_unit)
        {
                case FEET 		: return return_type(val*imperial::feet);
                 case LEAGUES 	: return return_type(val*nautical::leagues);
                case METERS 	:
                default			: return return_type(val*SI::meters);
        };
}

As long as you're happy to do internal calculations in a pre- 
specified unit
system, this should be all you need. Basically, as I see it, the  
space of
possibilities for quantity types looks like this

1) dimension and unit system fixed at compile time
2) dimension fixed, unit system free at compile time
3) dimension free, unit system fixed at compile time
4) dimension free, unit system free at compile time

Here,
1) is the zero-overhead approach I've implemented, 2) is the case where
unit system can change at runtime, but dimension is fixed, 3) is the  
case
where dimension can change at runtime, but unit system is fixed, and 4)
is the case of completely dynamic runtime units. Of these, only 1) is an
option if you do not want to pay a runtime cost for performing unit  
computations.
It is also the solution that has generated by far the most interest  
in this
mailing list over the many discussions of units and quantities.

Cheers,

Matthias