Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-06-12 19:43:30


"Janek Kozicki" wrote
> Andy Little said: (by the date of Sun, 11 Jun 2006 09:29:25 +0100)
>
>> > fixed_quantity,scalable_quantity,free_quantity
>> I did think of uni_quantity or universal quantity
>> Yes these names make more sense.
>
> of coure those are just my suggestion, you may as well decide to name
> them differently. The goal it to GET RID of numbers in names ;)

apart from in vectors ? :-)

> like this:
>
> rigid_quantity , scaled_quantity , uni_quantity
> fully_templated_quantity, partially_templated_quantity, runtime_quantity ;P
>
> whatever. but not numbers :)

What about in vector, say vector3d ? :-)

>> Yes, I should work on this mechanism of using the checked quantities only
>> for
>> debugging, but leaving no artefacts of them(like reduced speed) for release.
>> I
>> should also work on closing the gap betwen fixed_quantity and floats too
>> though.
>
> I hope that it will work. Or better - that with fixed_quantity the
> templates will work so good, that there will be no difference between it
> turned on and off.

It worked very well in VC7.1, in a previous version of the library, when the
assembly produced was identical to that for float types( but only for 2 small
simple tests and I didnt try further):

http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/perf_test.html

 VC7.1 has a very good optimiser and maybe that version of pqs was easier to
optimise than the current one. If that turns out to be the case I may have to
return to that design of implementation. In fact maybe I should try more
complicated tests on that implementation to see what happens and in gcc.

However I havent spent any time on that side of things with this version. I have
done a very different implementation, this time using a UDT member rather than a
float ( to separate the dimension from the units), which may be more difficult
to optimize, and I don't know anything about the optimiser in gcc. Currently I
have been more concerned with the interface than optimising the implementation.
Unfortunately in pqs_3_1_x the implementation is a mess. It needs stripping out
and redoing.

regards
Andy Little


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk