From: Simon Carter (simon.carter_at_[hidden])
Date: 2006-01-23 11:28:59
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