Re: The disturbing myth of Eiffel portability

[pcg@aber.ac.uk (Piercarlo Grandi)]

>>> "JYoungman" == James Youngman <JYoungman@vggas.com> writes:

JYoungman> In article <32b09c4c.252526073@news2.ibm.net>,
JYoungman> cjames3@ibm.net says...

cjames> All new development in US banks with European branches is in C++
cjames> back end and many front ends (none in Eiffel that I know of).

This does not mean that there are _no_ banks using Eiffel...

cjames> This is partly due to C with its silly pointers not scaling well
cjames> and mostly due to floating point problems at run time in C.

JYoungman> The runtime behaviour of C++ has just the same pros and cons
JYoungman> as that of C.

Those that have some idea of what C++ is about know better. It is very
easy to define a new data type, say 'Currency', in C++, and implement
precise arithmetic for it which is efficient at runtime, and which does
not suffer from the variable precision of the builting 'float' type.

In C one has the relatively unpleasant choice of either using the
builtin floating point datatype, whose variable precision is not
acceptable when dealing with (potentially large) sums of money (at least
without expending considerable analytical effort in range analysis), or
using a non encapsulated datatype and a library of external, non
inlined, functions.

This is both less convenient and (usually) less efficient than in C++;
for while C++ has inline functions, neither C nor ANSI C have them, and
using macros is not quite the same thing.

Indeed one of the _major_ design goals of C++, according to its authors,
is to allow the programmer to define new datatypes that can be used
almost as (e.g. wrt performance and syntax) a builtin one; this is
indeed possible thanks to the ability to overload operators and
functions and to suggest that the compiler inline them, and thanks to
the abiluty to encapsulate the representation of those user defined
datatypes (including ``intelligent'' pointers, as described above).

In this respect Eiffel is rather less attractive; user defined Eiffel
datatypes are not quite on a par with builtin ones either as to syntax
(which IMNHO is not important) or as to performance (which matters for
very fine granularity datatypes).

  It is rather significant IMNHO that Eiffel 3 has now expanded
  datatypes, which however small a detail, allows for _considerable_
  improvements in performance, in particular asd to garbage collection.

JYoungman> Is that your hat you are talking out of?  Funny place to wear
JYoungman> it...

Please keep such innuendo to yourself. Even if 'cjames3' occasionally
forgets it himself, this is in theory a technical, if informal,
newsgroup.