Steven Watanabe wrote:
AMDG
Noah Roberts <roberts.noah <at> gmail.com> writes:
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.
Not necessarily. static_multiply has to be able to operate on an mpl::list.
I don't know where you come up with that requirement. It certainly makes sense to me that if you have a library that is as intimately tied with MPL as this one is that you use the standards created by the MPL.
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.
I don't understand what you want beyond what is provided in conversion.hpp systems/si/convert_si_to_cgs.hpp, and systems/cgs/convert_cgs_to_si.hpp
quantinty<SI::length> l = 1.5 * ft; And no I don't really think ft being a quantity is adequate. quantity<SI::length> cent(cents); cent = 2 * meters; assert(cent.value() == 200); quantity<SI::length> unknown(user_unit); unknown = 5 * meters; quantity<SI::length> m(meters); m = unknown; assert(m.value() == 5); void f_cgs(quantity<CGS::length> l); f_cgs(quantity_cast<CGS>(cent)); The syntax is not necessarily what mcs does or would do but the concepts are what is important. It's been argued that this adds unnecessary complexity or would cause inefficiencies. I don't agree.