Matthias Schabel wrote:
To get things started, here are a few questions I have :
1) At the moment, the library enforces strict construction; that is, quantities must be fully defined at construction :
quantity<double,SI::length> q1(1.5*SI::meters);
is acceptable, but
quantity<double,SI::length> q2(1.5);
On the one hand it is useful to know what unit the value is in and to enforce such knowledge be explicitly stated in the code. On the other hand, since this library has no knowledge of units with conversion factors other than 1 in any given system...specifying the system in the template parameter is probably enough to say what is needed; the second use of the unit then could be considered redundant. I would leave the requirement since it necessitates that the developer know what unit they are working with in case they don't know the system and can't be bothered to look.
2) I'm not currently satisfied with the I/O aspects, particularly the lack of a mechanism for internationalization. I'd love to hear any design/implementation suggestions, especially from anyone familiar with facets/locales, on how to most gracefully accomplish this...
I don't think the unit library should do I/O. I think it is one area that would be better served as completely left out and let the user devise the method best suited for their I/O requirements, including i18n. Surely the developer knows what dimensions they need to be able to display and can do something as simple as overriding >><< for that purpose.
4) Any comments on implementation from those brave enough to look at the guts of the library would be especially welcome.
Since this library is heavily based on MPL it should use MPL constructs. Multiplying dimensions for example should be done with mpl::times<> instead of creating a new operator (multiply<>) for that purpose. It would also be good if the concepts were documented with concepts (the boost::concepts library) and enforced in algorithms. There is also a lack of meta functions to identify units and quantities as types (only dimensions have this functionality) for use in such things as enable_if and other meta programming utilities. I also disagree with the assessment that runtime unit conversions are unnecessary. It is my contention that the more common use for a unit library is to do conversions at runtime with minimal cost in an easy and efficient (from programmer perspective) way. Compile time dimension enforcement is a very useful tool but compile time unit enforcement without runtime conversion and unit selection is not. The target audience for this library, as specified, seem too small to warrant boost inclusion. That's my take.