Ralph Hempel <rhempel@hempeldesigngroup.com> writes:
Aladdin Lampé wrote:
Indeed, the calculations (Lua scripts) are provided by the users of
my application, and I don't feel like explaining in the
documentation that it is forbidden to test whether 1 <
decNumber.tonumber("1.5") and that what they should write instead
is: decNumber.tonumber("1") < decNumber.tonumber("1.5")...
Users of my original integrated float/integer complained about the
same thing.
Take a look at the C++ automatic type conversion rules. All of them.
They were clearly designed "cleverly" so that a user-defined "complex"
data type in C++ would have similar conversion semantics than the
built-in complex type in Fortran.
A whole bunch of complexity just so that one "non-native" feature
would
look like native elsewhere.
Unfortunately, what happens when you have
a) a complex data type that loses precision as compared to double or
integer data types
b) a Gaussian complex data type
c) arbitrary precision integral and fractional data types
d) modular arithmetic data types
The problem is that what C++ does with automatic conversions is
based on
assumptions about arithmetic data types and precision loss that are
simply invalid for a number of applications.
The complexity buys you one thing, and ruins a dozen other ones.
It is not worth it. Let the users whine about explicit conversions.
Better than the alternatives.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
