AMDG Noah Roberts <roberts.noah <at> gmail.com> writes:
Frankly put, I don't have a use for a library that does static unit conversions. We work in one system of units and convert into/out of those units when required to arbitrary units the user specifies and there are of course only a few dimensions we do this in. I have a hard time seeing a situation in which this isn't the way you would want to go about it.
As has been stated before, this library is primarily about type safety. The conversions are a secondary concern.
From what you are saying I think that you have not seriously considered what the implementation should look like. There are two basic possibilities
1) Store everything in some standard unit system and also store the conversion factor to the requested system. 2) Store the value in the requested unit system and remember the conversion factor to the standard system. How should addition and subtraction be defined? You cannot require that the operands have the same unit. Otherwise harmless looking code such as 1.0 * joules + (2.0 * kilograms * pow<2>(2.5 * meters / second)) / 2; might not work. Converting the second to match the first will work but loses precision. If you use 2. to avoid the precision loss brought about by the conversions involved in 1., by the time you are finished you will end up losing more precision than if you had simply converted to SI to begin with. Both of these require storing twice as much information as the current implementation. The inefficiency is probably more than a simple factor of two because the size increase will most likely force the compiler to continually load and store instead of keeping the values in a register. Any more complex approach will add even more overhead. For example, storing a sorted dimension list necessiates a call to merge for every single multiplication or division. In Christ, Steven Watanabe