--- Conversation with Bjarne Stroustrup on Slashdot. --- Questions: http://slashdot.org/article.pl?sid=00/02/25/1034222&mode=thread Answers: http://slashdot.org/article.pl?sid=00/02/25/1034222&mode=thread 9) C++ complexity vs. OOP simplicity by hanwen [Sorry for the potential inflammatory matter in this question]. How do you relate the complexity of current C++ with the much-touted simplicity of Object Oriented Programming? Longer explanation: Over the years, the C++ implementation has ballooned; If I recall correctly, your book the C++PL has more than doubled in size. C++ has become a very large and complicated language, and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart, let alone teams of programmers. This means that it is not practical to use C++ fully in any project, and one also has to set strict guidelines for a project what features to use and which not. Seen, in this light, it is doubtful whether C++ has made writing software more manageable. So I think, that as tool for writing better software more efficiently, C++ is a failure. C++'s evolution was motivated by a few mottos (you don't pay for what you don't use, C compatibility, etc.), and seen in this light, C++ is a success. Do you think that these mottos need reconsideration? Bjarne: Inflammatory? I think you are remarkably polite and technical here - and that your "editor/moderator" weeded out the real flames :-) Complexity has to go somewhere and I think that putting it in the language in the form of direct support of common and powerful techniques is a good idea (or else I wouldn't have done it :-). Have you seen C code that simulates class hierarchies, parameterized types, or exceptions? Such code tend to be a complete mess of pointers, casts, and macros. In C++, such code can be clean and simple. Most importantly, the constructs have well-specified semantics rather than just comments explaining the intent of code fragments. What has happened is that the complexity has been transferred from the code to the language definition (and compiler). You are right that there is little need to use all of C++ explicitly in every project. However, that doesn't mean that you need to impose restrictive "gudelines". When did you last use all of Unix or all of NT explicitly on a project? Would you like some manager to tell you exactly which OS facilities you could and couldn't use - independently of the nature of a project? The typical "guideline" is straight out of the dark ages, based on information about the state of the world years ago and on strange assumptions on what is and isn't complicated. In the defense of people issuing such "guidelines," it must be said that the educational establishment has on average done a poor job at focussing students on the key programming techniques that are effective in C++. The results have been much muddled C-style code combined with bloated Smalltalk-style class hierarchies. The common denominator for these sub-optimal uses of C++ is losts of casts and lots of macros. That said, I have seen many successful C++ projects (many more than failures) and much good C++. By good I mean, elegant, efficient, reliable, and maintainable. So, for many, C++ has delivered exactly what it was designed to deliver. Please remember that I made few, specific, and well-documented promises about C++ (See D&E and "The C++ Programming Language"). I was not a contributor to commercial OO hype. I think I see a correlation between successful use of C++ and respect for its limitations (the deliberate constraints on its design) and a willingness to adapt design approaches to the facilities offered. For example, if you reject the use of abstract classes and build deep hierarchies with lots of data defined at each level, you really shouldn't be surprised by long compile times, frequent recompilations, and problems understanding what is defined where. Similarly, if you refrain from using C++ facilities and litter your code with C-style strings, arrays, plain structs, and lots of pointers into low-level data structures, you shouldn't really be surprised to get C-style problems rather than the promised benefits from C++. The main tutorial presentation of the C++ language was 186 in the 1st edition, 282 pages in the 2nd, and 360 pages in the 3rd. Part of that increase is a greater emphasis on programming technique. The rest of the increase in book size (from 327 pages in the 1st edition to 1040 pages of the new special edition) is due to more information on programming and design technique, and the standard library. The "special edition" has 363 pages on the standard library - in addition to the uses of the standard library as examples in other parts of the book. ******************* Thanks for answering my question. Now that I am reading your replies (and of course after reading your FAQ as well), I've started to notice that your replies center on the fact that C++ is better than C Or maybe even the less subjective Complicated programs in look better in C++ than in C This is patently true, of course. C++ has support for various nifty features that make a large C project more easy to manage. In fact it describes precisely what I felt when I traded C++ for C: no more hassling with function pointer tables was needed. I could simply use a virtual function, great! My problem is "better than C" is no longer good enough for me. I've grown a lot in my programming skills, and my projects have grown with me. A little detour: my pet project is GNU LilyPond, a music typesetter (free software of course) written and maintained largely by myself: it consists of about 55000 lines of C++. The problem with this application is that 1. music typesetting is _very_ complicated 2. every formatting detail should be tweakable. Since I've started it almost 4 years ago, I've learned a lot, and also came in touch with languages like Python, Haskell and LISP. Half a year ago we made the step of converting large portions of the C++ side to GUILE (the embedded Scheme interpreter of the GNU project). This step has dramatically simplified most of the code in LilyPond: now we have garbage collection, generic types without the overhead templates!, a clean way for users to plug into this system using Scheme, etc. (if you want details of what kind of uglyness went away, tell me, I can explain). This revelation caused to me reconsider C++ as the ultimate language. In python, I can simply write for x in func1, func2: [some complicated code with x] in C++, I'd have to go through the hassle of defining the correct function signature as a typedef, then build an array, and then loop through that array using an integer, eg. typedef void (*fptr)(); .. fptr[2] = {&func1,&func2} for (int i=0; i < 2; i++) [some complicated code with x] And usually, I don't go through the hassle , and just copy and paste [something complicated], which is also a Bad Thing. Maybe this is a slightly contrived example (I'm not sure about the typedef), but learning Python and LISP has made writing C++ a generally painful experience for me. Maybe nowadays some of my gripes may be soothed by the Standard Libraries, but I don't feel like learning yet another big C++ component, all the more because I know that afterwards C++ will still not be good enough (or will it ever have reflection, higher order functions, GC?) In this light, I find your statement that starting to learn C++ is easier than starting to learn C dangerous, as are the examples in your "learning C++ as a new language paper" for they imply that any of these two languages can or should be a "first" language. Do you really want people grow up with a language that has distinction between non-immediate objects on the heap and stack, no automatic garbage collection, pointers, no initialization, no higher-order anything? You're educating people about C++: fighting misconception, telling them where it is good for. But you're not telling them what it is bad for. C++ is immensely popular, and people easily get the misconception that this popularity makes it a good language start programming with, or to write their highly tweakable programs, etc. Han-Wen Nienhuys -- LilyPond (http://www.lilypond.org)