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