From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-12 16:17:45
Steven Watanabe wrote:
> 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
>> 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
quantinty<SI::length> l = 1.5 * ft;
And no I don't really think ft being a quantity is adequate.
cent = 2 * meters;
assert(cent.value() == 200);
unknown = 5 * meters;
m = unknown;
assert(m.value() == 5);
void f_cgs(quantity<CGS::length> l);
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.