This looks most interesting, and there most definitely remains a great need for a units handling package.
Definitely!
- SIUnits includes some "advanced" features which introduce run-time cost, while my library does not include such features. The main example is the ability within SIUnits to change at runtime that a dimensioned quantity should be displayed in terms of various units (introducing an automatically applied scale factor) and with various labels (used when printing). While I "power user" could implement this within my framework (e.g., by specializing scale and label in mks_tag), I don't see much point. If I want a time in years rather than seconds (default in mks), I can easily write cout << time_till_graduation / year;
I have found in the past that there is a need to distinguish between dimension handling and unit handling.
In the case of a physical calculation, I usually ensure that the code works with a self consistent set of units, and thus only need dimensionality, compile time, code.
Units then become important only in the user interface, and I have a list of the units used in the physical calculation for each dimension.
This is obviously only one way of using dimensions and units, but I think an important one. The usual exception to the above is for money where you are working with multiple currencies.
A couple of use cases, that I am unsure would be handled by the current proposal:
I have a "Cost" class that records costs for different factories in different countries. The "unit" used for each is factory is different, eg USD for factories in US, GBP for those in UK. ie the unit varies per instance.
A similar situation occurs for "dimensions" of physical units. eg. if you want a list of quantities used per output weight or output pieces, then each item in the list has different dimensions, eg. Watt seconds/time, Litre/piece, number/kg. In this case I obviously have to give up the type checking, but still need to be able to record a dimension, to allow display in appropriate units.
- My library allows for users to add qualifiers to dimensioned quantities which are strongly typed by default. Users may choose weak typing (e.g., automatic conversion from mass of apples to mass of fruit or allowing a sum of mass of apples and mass of oranges to equal a mass of fruit) by relatively easy specializations.
Excellent!
Hugo
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
