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

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2007-02-14 12:44:02

Steven Watanabe wrote:
> AMDG
> 
> Noah Roberts <roberts.noah <at> gmail.com> writes:
> 
>> "Converting the second to match the first" doesn't make sense to me.  I 
>> guess you might be talking about operands of '+'?  Yeah, not necessary.
>>
>> The answer is pretty simple.  All arithmetic operators work in the base 
>> system.  The result is converted on assignment if necessary.
> 
> Ok. What happens here:
> 
> std::cout << (x + y) << std::endl;

Nothing good would probably come of it the way I see things; but since 
mcs does magic unit label stuff it could just output that.  Without, 
allowing for the user to override certain behavior this could be more 
well behaved:

std::cout << ((x + y) * unit) << std::endl;

You're probably not too worried about the moderate overhead of the extra 
work there when I/O is going to be bottlenecking anyway.

Except in debugging, the developer is going to have a pretty strong idea 
of what units need labels and create them.  Other units and dimensions 
are of no consequence.

> The former is exactly what I said.  It stores
> two doubles instead of one. Further,
> 
> temp = a + b;
> c = temp * d;
> 
> is not equivalent to
> c = d * (a + b);
> 
> Every operation incurs an extra multiplication
> per operand.  This is a far cry from zero overhead.

But you don't have to pay this cost unless you need to.  Imagine:

class qty_withunit;
class bare_qty;

template < typename T1, typename T2 >
bare_qty operator * ( T1 const& l, T2 const& r) { return bare_qty(...); }

greatly simplified for posting purposes...the return type alone is a few 
lines of code.

quantities have assignment ops that react to anything that is_quantity<> 
as do all operators.

You then write your functions like so:

bare_qty f(bare_qty) { some calcs and a return; }

and use them like so:

qty_withunit x(unit);
x = f(x);

and possibly:
qty_withunit y = f(x) * unit;

Yes, there is an overhead to the unit but it is localized to the places 
where conversion is necessary.  The library user does have to use some 
care, and I haven't thought of a way to allow them to use this stuff 
willy nilly in something needing extreem performance, but I don't think 
that is too much to expect.