Boost logo

Boost :

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


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
> 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'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
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
a specified dimension but with runtime-varying unit system. That is


would represent a length in any unit system you wanted, where the
unit system can change dynamically. But, to get back to Steven's
what would this support that the existing library with explicit (and
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

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at