Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!espresso.internet-cafe.com!usenet From: Bertrand Meyer <bertrand@eiffel.com> Newsgroups: misc.jobs.offered,comp.lang.c,comp.lang.c++,comp.lang.c-cat,comp.object,comp.lang.eiffel,alt.syntax.tactical,comp.lang.misc,comp.unix.bsd.386bsd.misc Subject: [--] Re: Beginner to C/C++ looking for some good books Date: 23 Aug 1995 18:01:04 GMT Organization: Interactive Software Engineering Inc. Lines: 62 Message-ID: <41fqd0$jp0@espresso.internet-cafe.com> References: <40b4i2$egf@ixnews5.ix.netcom.com> <brockmanDDLJDL.2IJ@netcom.com> <41alha$b1g@cisunix1.dfci.harvard.edu> <DDowtJ.KL6@research.att.com> NNTP-Posting-Host: outback.eiffel.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3 sun4c) To: ark@research.att.com X-URL: news://london/DDowtJ.KL6@research.att.com Xref: euryale.cc.adfa.oz.au misc.jobs.offered:196183 comp.lang.c:110937 comp.lang.c++:121391 comp.object:30947 comp.lang.eiffel:9011 alt.syntax.tactical:926 comp.lang.misc:17141 comp.unix.bsd.386bsd.misc:142 From Andrew Koenig <ark@research.att.com>: > C++ is not philosophically unsound. It is a consistent expression > of the viewpoint that C programmers should not be forced to discard > their existing code and knowledge in order to be able to program > in a more abstract style. Since, among others, the quoted message was posted on comp.lang.eiffel, it is perhaps useful to note that Eiffel certainly is not an "expression of the viewpoint that C programmers should ... be forced to discard their existing code and knowledge". Andrew Koenig did not write as much but one could draw from his statement the a contrario impression that languages other than C++ promote such a viewpoint. Here the difference between C++ and Eiffel is not about the need to retain compatibility with existing C software; everyone agrees that this is desirable. The difference is about how to go about retaining such compatibility. The C++ view promotes compatibility at the language level. The Eiffel approach holds that a language should remain simple and consistent, and not try to be two radically different things at once - C and object-oriented -, which risks leading to a language that is too complex, and unsatisfactory on both counts: not as good as C as a simple, efficiently compilable machine-oriented language; yet not delivering the true benefits of object technology because it is hampered at every step by the yoke of C compatibility (in areas such as memory management, type safety, modular structures, syntax, pointers, array handling etc.). Instead, the Eiffel view is that we should have a language that is object-oriented all the way through, while providing clear and clean communication paths with the non-O-O world, in particular the C world. Hence the possibility of declaring an Eiffel routine as being external and written in C, so that any call to the routine, viewed as a normal Eiffel call by the Eiffel side, will actually trigger the associated C function or macro; and the presence of a library (CECIL) that provides communication in the reverse direction, enabling C software to create Eiffel objects and apply Eiffel features (routines and attribute accesses) to them. I find this approach preferable to the C++ one. It enables a smooth transition, retaining the benefits of existing code and competence, and it draws a clear line between the two technologies, accepting that C is not O-O and O-O is not C. -- Bertrand Meyer, ISE Inc., Santa Barbara 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> Web home page: http://www.eiffel.com ftp://eiffel.com (The "label pin" [..] indicates adherence to the SELF-DISCIPLINE program for better Usenet discussions. See http://www.eiffel.com/discipline.) P.S. I hesitated about where to post this message. The groups line is obviously too broad, but for a direct response it seemed OK to retain the original. If I have to post any further comment I will narrow the list down to the most relevant groups: comp.lang.c++, comp.lang.eiffel and perhaps comp.object.