"Simon Carter" wrote
I think this library is extremely useful.
Great. The only thing I don't like (on first
pass) is the use of the default_value_type thus:
struct length : length_<quantity_traits::default_value_type>{};
I'd prefer to explicity specify the type every time I used it so:
length<int>::m
This option is of course available by adding the '_' suffix to the quantity name: length_<float>::m; length_<long double>::m; I am not blown away by this useage of the trailing underscore on the quantity name as I am aware that it is popular to use the trailing underscore for member data, but I cant think of anything better. Suggestion welcomed. The useage : length::m is simply a convenience. BTW The default_value_type is usually set to a double but can be changed to eg float by (slightly obscurely I now observe) changing the BOOST_PQS_REAL_TYPE defined in <boost/pqs/config.hpp> An alternative to the above scheme would be to provide a namespace for one or each type : boost::pqs::implicit_param::length::m; boost::pqs::explicit_param::length<int>::m; with the idea to use a using declaration to select one of them : using boost::implicit_param::length; This approach has seemed messy to me., but I am open to ideas.
Then perhaps pqs could extend its remit to include checking for loss of precision as well as dimensional analysis.
Older preboost versions of pqs used boost::numeric::converter which threw an exception (subject to a policy) when an out of range conversion occurred eg when say a runtime double value_type has a value too big for an int. It got lost in all my changes. I shall put that back in to the system next version Is that the type of thing you mean or do you mean something else such as keeping track of the precision ? Glad you broadly like the library ! regards Andy Little