Re: [boost] mcs::units informal review request

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-12 16:17:45

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.