Re: [boost] pqs_3_0_2 available in the Boost.Vault

From: Andy Little (andy_at_[hidden])
Date: 2006-01-18 18:24:46

"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