AMDG "Eric Lemings" wrote:
<snip>
Undoubtedly, the scope of this library should include the dimensional analysis framework which defines the fundamental types/metatypes (e.g. dimension, unit, quantity), their semantics, and their operations. It should also include only the most common dimensions such as the physical dimensions (time, length, mass, etc.) and allow, at least, other universal dimensions (e.g. currency). Other, more specialized dimensions should be defined elsewhere.
That was one of out goals. The units that we have are implemented solely in terms of the dimension/unit/quantity framework.
The scope should not include any facilities for input and output. It should also not prevent such support however. (Input and output of units and measures can be handled by extending C++ locales with new facets. C++ locales already deal with I/O of time and money. More about internalization and localization below.)
Input is definitely beyond the scope of the library. We have implemented primitive output.... On further thought, we should probably just have an output operator for quantity that prints the value_type then the unit and leave unit output alone.
The scope should not classify units of measurement into exclusionary systems. True, many programs/programmers will have restrictions that prevent/exclude use of any units of measurement outside a well-known set of units but the other extreme is also quite possible. A program may allow arithmetic/conversions between any and all units known to the development/operating environment. In such cases, the programmer is not concerned in the least with systems of units and classification of units into systems becomes totally irrelevant (and impossible for many older and rarer units of measure). Therefore, if constraining units into discrete systems is a desired objective, it should be the responsibility of the program rather than the library.
Allowing conversion between units having different dimensions and allowing fundamental units whose dimensions are not fundamental e.g. quarts for volume is very very difficult to implement. Off hand, I think that it requires defining some special system (probably SI) and converting through that system.
Whether the scope should include a particuar system of units (e.g. SI units, Imperial units) is debatable. Personally, I believe each system of units should be treated much the same way C++ currently treats locales. The library may contain, even mandate, a "default" set of units (e.g. SI) but including even the most common modern units is beyond the scope of the library. (Which units are modern? Which units are common?) Each system of units can therefore be defined separately as an extension to the underlying framework.
Absolutely
I'll post more specific review comments about the proposal later.
Thanks, Eric.
Thanks! In Christ, Steven Watanabe