Robert Graham Merkel <[EMAIL PROTECTED]> writes:
> It's a good thought, and the use of C++ operator overloading is
> convenient for this kind of thing, but there is a rather large
> problem.
C++ operator overloading is almost never the right thing to do, IMO.
The operators already have meanings of their own, and they never quite
match the semantics of the overloading function, so you end up having
to read the 'foo_t::operator+' code anyway just to see exactly what it
means to '+' two foo_t together. If it's not obvious exactly what it
means to add two foo_t together with + when you see it in the code,
then the syntax is obstructive and you'd be better served with an
explicit function call that doesn't fool the eye into thinking
something different is happening than actually is.
In this case, if we are going to use a completely different number
representation, does anyone actually believe it's just going to be a
matter of defining a class and then piping the code through sed -e
's/double/GNCNumeric/g' ? We're going to have to rewrite a big chunk
of the engine and the surrounding gnucash application to make it work
right. I think it's the right thing to do, but in this case it will
be a LOT better to have all our dependencies on double math cause
blatant compilation errors rather than be silently made to "work" by
the existence of an operator+ for the new type.
The semantics of adding numbers together (and subtracting, and
multiplying) is very different when the operation could result in the
loss of information, and when the application needs to control the way
in which that information is preserved or discarded. Not to mention
that we have to put an entire infrastructure in place for handling the
appropriate precision of representation throughout the application,
and for converting values to and from our "special" number
representation for input and output.
I have enough experience with c++ to be very, very skeptical about the
possibility that it will be a net win for us. c is bad enough about
encouraging you to shoot yourself in the foot; c++ practically pulls
the trigger for you.
> However, if we can't find a C library for doing this that meets our
> needs, turning fixpoint arithmetic code that we write
> into a library that could be used for other applications is worth
> some careful consideration.
Please be careful about use of the term "fixpoint". It implies that
the smallest-countable-unit is related to the unity-unit by a
power-of-ten relationship. That's true for US Dollars, but it's not
something we can assume for other currencies or for other numeric
values that we will want to represent in this format. Even if we
*can* find a fixed-point library out there, it's not what we need,
IMO.
Bill Gribble
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
