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