Christopher Browne <[EMAIL PROTECTED]> writes:
> The effects are unfortunately pretty sweeping; every place where you
> manipulate a currency amount, you have potentially to rewrite it to use a
> function, whether
> add (&dest, a, b), mult (&dest, amt, scalar), or whatever.
>
> This is one place where the ability C++ provides for operator overloading
> would in fact be quite valuable; that would allow manipulations to become
> pretty transparent, replacing the calls above with:
> - dest = a + b;
> - dest = amt * scalar;
Well, I'm really not a big fan of operator overloading (it's one of
the reasons I'm somewhat on the outs with C++ these days). IMO, that
feature, combined with somewhat complex precedence rules and implicit,
potentially chained? coercions, can often make reading other people's
code, and sometimes my own (before I started avoiding this stuff
more), fairly difficult to follow. I find it can make it hard, unless
you're really familiar with the code *and* the rules to figure out
what's actually happening.
x + y
could conceivably call a bunch of functions (if C++ supports chained
coercions (I'm not sure it does), and unless you *very* carefull trace
the type graph, you won't know exactly which functions are being
called. Further, add one more coercion, and you could change
computation all over the place.
It's funny that some C++ people don't think any of this is a problem,
and yet really get excited about dynamic types. To me the former is
much harder to follow. Oh well, YMMV.
If we were to do this, I'd actually prefer things like:
frac_mul(frac_add(x, y));
or code similar to what you posted with the references. To me, then
it's obvious what's going on.
> There's a certain amount of further merit to this, as the
> consideration that you have "scalars" versus "currency amounts"
> provides some typing information that might diminish the incidence
> of errors in new code that gets written.
This is probably true, though I think Linas is probably right that
double precision floats should be more than enough for the kinds of
things GnuCash is targetted at.
FWIW
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
