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

From: Andy Little (andy_at_[hidden])
Date: 2006-01-23 19:07:54

"Simon Carter" <simon.carter_at_[hidden]> wrote in message 
news:loom.20060123T172320-254_at_post.gmane.org...
> 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.

OK I will have to set up a FAQ in the documentation regarding that subject. 
There are problems with the current scheme its true.
My feeling ( and the reason I  used this scheme) is that the vast majority of 
use cases use the default ( double) value_type for a quantity and that the 
current scheme aids legibility. You do suffer if you dont want to use it though. 
Changing the default (eg. to a float) is possible in the  <pqs/config.hpp>  or 
<pqs/quantity_traits.hpp> files.  I could  suggest the default mechanism  to the 
user as a way around having to type out the double parameter rather than forcing 
it on them I guess.

>> > 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.

You mean disallowing (say) double to int conversons and so on? I am pretty sure 
that would be possible via a policy in Boost.Numeric Converter. It is possible 
to modify this too. Its currently at line 93 in <pqs/quantity_traits.hpp>. I 
will have to raise that as  question  in the documentation too. As it stands I 
have used the default converter action but using round-nearest rounding scheme.

BTW  conversion isnt working properly in pqs_3_0_4 . I am converting too early 
for Boost.Numeric Converter to do its job. Todo for next version.

regards
Andy Little