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: 103376,dad65365cb2b3396 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,bdaddde464f6e704 X-Google-Attributes: gid1108a1,public X-Google-Thread: 1014db,dad65365cb2b3396 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,dad65365cb2b3396 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,bdaddde464f6e704 X-Google-Attributes: gidf43e6,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/27 Message-ID: #1/1 X-Deja-AN: 201032863 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <3294e64b.74799475@news2.ibm.net> <32b09c4c.252526073@news2.ibm.net> <56q0kp$ma0@halon.vggas.com> <57172k$325@miranda.gmrc.gecm.com> content-type: text/plain; charset=US-ASCII mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng Date: 1996-11-27T00:00:00+00:00 List-Id: >>> "paul.johnson" == Paul Johnson writes: paul.johnson> In article , paul.johnson> pcg@aber.ac.uk says... pcg> [ ... ] In this respect Eiffel is rather less attractive; user pcg> defined Eiffel datatypes are not quite on a par with builtin ones pcg> either as to syntax (which IMNHO is not important) or as to pcg> performance (which matters for very fine granularity datatypes). paul.johnson> Syntax first: I think you will find that the built-in paul.johnson> Eiffel data types are on a par with the user-defined ones: paul.johnson> unlike C++ things like integer and array are defined as paul.johnson> classes. Well, only in Eiffel 3, which is a rather different language from Eiffel (despite backwards similarity); and even in Eiffel 3, they are a bit more special than user defined types. BTW, it's clear that different people mean different things with ``Eiffel''; the various versions of the language are rather different. The same applies to ``Ada'', ``C'', ``FORTRAN'' and also to ``C++'', where one never really knows _which_ version of the language is being discussed, for while for example for Ada and C and FORTRAN there is a customary indication of version (Ada 83 and Ada 95, C and ANSI C, FORTRAN 66, FORTRAN 77, ...) I have very rarely seen any usage of the C++ 1.0, C++ 2.x, C++ 3.x or C++ draft ISO @ [date] labels. In part this is because C++ implementations often implement bits from several versions... What has most impressed me in the changes between Eiffel and Eiffel 3 is the obvious change of many important design decisions, and the giving of much greater importance to aspects that have always ben central to the design of C++ (there are many examples: from 'expanded' to 'bit N'). If Eiffel had been designed from the start as a more C/C++ like language, the ugliness of certain aspects of Eiffel 3 could have been avoided... paul.Johnson> Efficiency: see the thread about benchmarks. Where paul.johnson> exactly do you think that user defined data types lose paul.johnson> performance? Memory management, for like in SIMULA, they ``must'' be heap allocated, and accessed indirectly via pointers/references (and without something like the 'WITH' construct of Pascal or block prefixing as in SIMULA). In Eiffel 3 they _need not_ be heap allocated; but then there are other aspects that more or less mandate the existence of a system builder, which is indeed duly provided (certain overheads can only be avoided if a program-wide optimization is done), but which causes its own difficulties (convenience more than performance). pcg> It is rather significant IMNHO that Eiffel 3 has now expanded pcg> datatypes, which however small a detail, allows for _considerable_ pcg> improvements in performance, in particular asd to garbage pcg> collection. paul.johnson> More importantly, it has allowed the builtin data types to paul.johnson> become part of the class hierarchy. Well, this is elegant indeed (except for abominations like 'NONE', which was justly criticized in the discussion of Eiffel in OOSC); but I think that the problem with having all non-primitive values accessed by reference and in the heap was a far bigger problem as to the practicality of using Eiffel than the inability to have basic types part of the class hierarchy.