From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,dad65365cb2b3396 X-Google-Attributes: gidfac41,public X-Google-Thread: 1014db,dad65365cb2b3396 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,dad65365cb2b3396 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,bdaddde464f6e704 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,bdaddde464f6e704 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,dad65365cb2b3396 X-Google-Attributes: gid103376,public From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/20 Message-ID: #1/1 X-Deja-AN: 197660021 sender: pcg@osfb.aber.ac.uk references: <3294e64b.74799475@news2.ibm.net> <32b09c4c.252526073@news2.ibm.net> <3292AF39.58E8C833@probe.net> organization: Prifysgol Cymru, Aberystwyth newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng Date: 1996-11-20T00:00:00+00:00 List-Id: >>> "jmiller" == Jeff Miller writes: jmiller> The Rt Rev'd Colin James III, KOTM 1/96 wrote: cjames3> Eoin Woods is deluded in the article quoted below. Ah well, perhaps you should phrase this in a less personal way :-). cjames3> Almost all banks still do most of their processing in COBOL. Well, indeed, if one is considering back-office processing; but their front-office applications are nowadays indeed mostly done, in the more progressive banks, in: cjames3> All new development in US banks with European branches is in cjames3> C++ back end and many front ends In many cases these front-ends are C++ based too... cjames3> (none in Eiffel that I know of). This is partly due to C with cjames3> its silly pointers not scaling well and mostly due to floating cjames3> point problems at run time in C. I don't think that the definite advantage that C++ has as to the ability to define ``intelligent'' pointers is much relevant to why banks use C++ instead of C for front-office developments, so I would not consider it even a partial cause ("partly due"); IMNHO the major cause is perhaps the fashionability of C++. As to technical reasons I can agree that perhaps the strongest ("mostly due") one is indeed the ease and efficiency of adding a multiple precision numeric type to C++, which obviates the variable precision properties of floating point arithmetic in C. jmiller> Could you elaborate on the way pointers in C restrict jmiller> scalability? Well, there is not much need to: there is an ample literature (just use some WWW index to search for either "intelligent pointer" or "pointer swizzling" for many references to the two concepts) on the possibility to define ``intelligent'' pointer datatypes in C++, in a way that is impossible in C, and then uasing those to implement the ability to do pointer ``swizzling'' and other techniques (mostly inspired by Smalltalk-80's LOOM and other similar technologies in Lisp Machines) that allow a program to manipulate a set of objects potentially much larger than that which can be contained in the address space visible to a program (depending on how large the latter is).