
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.