3) implemented quantity_cast for three cases (see unit_example_5.cpp) : a) construction of quantities from raw value types b) conversion of value_types c) conversion of unit systems
It isn't clear to me what the semantics of these three are. I'd
Semantics are : a) construct quantity from value_type double x = 10.0; quantity<length,double> q = quantity_cast< quantity<length,double> >(x); b) change value_type quantity<length,double> y = 10.0*meters; quantity<length,std::complex<double> > q = quantity_cast< std::complex<double> >(y); c) change unit system quantity<SI::length> z = 10.0*meters; quantity<CGS::length> q = quantity_cast<CGS::length>(z);
quantity_cast should be a dimensionally safe operation. Is that the semantics you have in mind?
I was thinking the opposite - i was under the impression that explicit casting usually indicates something that's potentially _unsafe_...
It seems like (a) should just be handled by multiplication. That is, double x = 42.0; quantity<SI::length> y = x * SI::meter;
This is the default method for quantity construction.
For (b), it might be better to have a static_quantity_cas, as in quantity<SI::length> x = 42.0 * SI::meter; quantity<SI::length, int> y = static_quantity_cast<quantity<SI::length, int> >(x);
I guess I don't feel strongly one way or the other - using quantity_cast as the syntax for all three conversions is simpler since there isn't any potential for confusion, but I'm happy to go with the flow if there is consensus otherwise.
For (c), do you mean this: quantity<SI::length> x = 42.0 * SI::meter; quantity<CGS::length> y = quantity_cast<quantity<CGS::length> >(x); where y ends up being 4200 cm?
Exactly. There are essentially three components to a fully-specified quantity: the unit system, the unit type, and the value type. As it is implemented now, quantity_cast allows casting of all three of these...
PS I must say I'm thrilled to see someone putting serious effort into this. I've thought about it for years.
I'm glad for the interest...obviously there's been a lot of discussion of this kind of library in Boost over the past few years. Because many of these have been contentious, I'm trying to get as much early feedback as possible so I can make the library as flexible as possible without having it grow beyond control... Please let me know as you have a chance to play with the code and docs if you have other concerns, suggestions for improvement, editorial input, etc... Cheers, Matthias