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,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public From: Bart Samwel Subject: Re: What is wrong with OO ? Date: 1997/01/06 Message-ID: <32D11FD3.41C6@wi.leidenuniv.nl>#1/1 X-Deja-AN: 208076520 references: <5acjtn$5uj@news3.digex.net> content-type: text/plain; charset=us-ascii organization: Dept. of Math. and Comp.Sci.; Leiden Univ.; Leiden; the Netherlands mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP22) Date: 1997-01-06T00:00:00+00:00 List-Id: Bjarne Stroustrup wrote: > Only where I couldn't find a solution that fitted in C++'s general > framework and met my criteria for run-time efficiency, ease of > implementation, ease of teaching, etc. (see D&E Chapter 4), did I > feel compelled to try to invent something. When I read this, a lot of questions pop up in my head. I'll ask only one: You've only included features that didn't compromise ease of teaching (at least, that's my interpretation of what you wrote). Why is it then, that C++ contains so many hidden 'features' (or rather, non-explicit rules) that confuse people, at least at my university? As far as I'm concerned, C++ is not a language for teaching. It has too many of these implicit rules to be logical, and the fact that it doesn't have garbage collection and does have pointers really makes it error-prone; especially for beginning programmers, this is not a good thing. They should be writing WHAT should be done, and ALL that should be done; they shouldn't be bothered with the 'how' part of programming, like (with alternatives): memory management (garbage collection), pointers (references), virtual functions (can be detected by the compiler). They should not be bothered with implicit rules (like the multiple inheritance rules, for instance) that they have to know of, before using multiple inheritance. C++ is an excellent language as an extension to C, but C is altogether obsolete and much too low-level, except for systems programming, and other languages are now available for writing high-level software. Many people make the (IMO huge) mistake of using C++ for high-level software projects, leading to buggy results and, often, lots of core dumps. Programmers are not perfect, and C++ expects them to be so by providing too many ways of making mistakes. Languages like Eiffel (my personal favorite) are much more suitable for high-level projects; Eiffel, for instance, does not burden the programmer more than needed, and has a clean, clear syntax that can even be immediately understood by people that don't know the language. > Much of C++'s success has to do with fitting into existing > environments and being compact and fast (yes, I know that these are > not the aspects of C++ that are currently emphasized in the > MS Windows world). The speed and compactness of code generated from > C++ depends on a few fundamental design decisions that I think were > novel at the time: Speed and compactness is certainly a goal that C++ has achieved. But it did not achieve one major goal: ease of use. > C++ offers inline member and non-member functions with zero > overhead compared to macros. You shouldn't bother programmers with inlining. Inlining can be done automatically by the compiler. > C++ offers its form of dynamic (run-time) resolution, virtual > functions, with low and fixed overhead compared to ordinary > function calls (20% to 100% dependent of implementation). Virtual functions must be explicitly specified. This can be done by the compiler. And, virtual functions must be specified in the ancestor class; this means that when a class designer forgot to put that in (and this happens often), I can't redefine the function correctly. > Over the years, C++ has evolved within a framework that was reasonably > well understood early on. Well understood, yes. But the framework is now obsolete, and it has some serious design flaws that also bother C++ users. Bart Samwel (bsamwel@wi.leidenuniv.nl)