Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
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.
I think I would prefer to always explictly specify the underlying type and do away with the defaults, but perhaps I'm odd.
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 ?
I did mean exactly this - out of range conversions - but it would be much nicer to see a compile-time failure when it is possible that a value can be too big rather than an exception when the conversion actually fails. Simon