"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
"Eric Ford" <un5o6n902@sneakemail.com> wrote in message news:10855-92248@sneakemail.com...
The next version of my physical quantities library pqs-1-01-04 is available on my site at:
http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html ...
Andy, Thank you for your work on this very important area of development.
Thanks!
From just quickly looking at the examples, it appears that you choose to use different types for quantities that have the same dimensions but different units. I don't think that is a good idea. You can search the archives for the discussions several of us had about similar issues, mostly a few years ago. If you still disagree, I'd like to hear why.
Firstly, the units are part of the Type of a concrete quantity. If you cant declare the whole type at compile time you cant use in templates or whatever. Secondly the value is internally at the scale of the unit, because,you will always be working at some particular scale and will get the best resolution and range for that unit, which is surely where you want to be. The unit prefix is embedded in the template parameter representing the exponent to base10 of the unit, ie mm --> -3 ,km --> 3 etc.( km or um is just as valid as m for represnting length in SI) multiplication and division resolves to adding and subtracting exponents (at compile-time). At run-time only the values themselves need to be mux/divided. In case of addition/subtraction of differing units run-time conversion to one or other will occur, however usually addition and subtraction is only between dimensionaly exuivalent quantities at similar scale. In multiplication and division OTOH, a different quantity will often result, which might be at a much different scale, but due to the compile time tracking of exponents no resolution is lost...only the internal values are muxed/divided. In fact it works much like manual calculation, cancelling powers and so on. Finally (for example) energy and torque are dimensionally-equivalent, but not the same quantity, so they must have different units.
Perhaps, you could summarize the main similarities and difference between your library and other similar libraries.
As for similarities, yes I have drawn a lot from all those libraries. I originally came on boost because I had heard that there were some physical quantities libraries there. I have looked at most (all )of them including yours, however as is my usual practise I couldnt avoid starting to reinvent the wheel. Most of those libraries were built before the latest generation of compilers and I freely admit that things get much easier once (1) you have the tools. (Thanks to All those compiler vendors who only ever sem to get complaints from us coders) and (2) someone has done it before you. One other important fact is documentation. I dont say mine is good (yet), but however good the library is, if its not documented, its going nowhere. (Personal note: Get on with the documentation! ) In many of the libraries on the boost file section the units are applied at initialisation, but initialisation happens at run-time, not compile-time. Therefore you cant throw around types representing concrete-quantities at compile time. In the current version of the library I have some examples that use the ct-quantity (compile-time quantity... units fixed at compile-time ) as a building block for other things. One is the rt-quantity (run-time modifiable units ). Another derived from rt-quantity is the mapped-rt-quantity which has units which can be set via strings. At this point the combination is pretty versatile and you can start to use it right from the application user level ie drop-down lists etc to something at a lower level which has a good run-time speed performance.All unit conversions are checked at compile time, because all these types are ultimately based on the compile time type. For example the strings represent ing units input by the user, are compared against a map generated from the stream output of the ct-quantity units. Units are added in the mapped quantity like so: mapped_length length; length.add_unit<q_length::m>(); length.add_unit<q_length::mi>(); etc. User can set units and/or value etc like so: if( length.set_quantity(100, "m") ){...} The run-time quantities are entirely compatible with the ct-quantity and so you can cast betwen them
For example, there's Walter Brown's SIUnits, as well as a couple of drafts that have been uploaded to the boost vault. I know I posted ebf_units a while back to give people something to work from. And I believe there were one or two others there as well.
SIUnits is a ground-breaker, but all the innovation happens underneath the surface. Many libraries are based on its user interface, but I dont think that is so good. In my library I have tried to look more closely at the user interface, to give the types an instinctive 'look and feel' etc, for simple coding. It aims to be useful rather than to have an arguably pretty syntax. regards Andy Little