Part of how C++ is successful is that it retains C compatibility, and C accurately models how the computer actually works (at least computers of the 70s and 80s, which is all we know how to program well). Lovely languages like lisp, python, haskell may be nicer to work with, but they do not model the underlying machine properly, and for so many problem domains that is just not acceptable. It's not just a performance question.
And then C++ implements several programming paradigms (object oriented, generic, etc) without compromising that machine model.
Plus Bjarne was truly correct when he said: "there are languages people complain about, and there are languages nobody uses."
Bjarne was truly correct when he said: "there are languages people complain about, and there are languages nobody uses."
I think this is very true, what it says literally is that popularity and attracting ire are correlated.
However, my interpretation is that the reason why this is true is that (1) all languages involve design trade-offs, (2) every trade-off pisses someone off for at least a moment, and (3) popularity attracts eyeballs, therefore more popular languages have more people pissed off.
I am not suggesting you say this, but I have heard the (strawman?) argument that it is possible to design a nice, pure language that is above reproach but that it can't be popular, and thus his quote expresses the thought that there is an inverse relationship between elegance and popularity. I don't think this is the case.
I think C models how the computer works a lot more closely than C++ (and no one would argue that C isn't carrying water out in the engineering world even today). IMO C++'s issue is precisely that it layers all of these leaky abstractions on top of the strict procedural model of C.
For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.
The chief problem with the idea that C "accurately models how the computer actually works", as you allude to but don't go into detail, is that modern CPUs work nothing like the CPUs that C is accustomed to. Between out of order execution, hyperthreading, caches, prefetching, pretending-to-be-uniform-memory-access-but-not-actually-being-it and concurrency the degree to which C's computer model is relevant is rapidly shrinking. We don't really have a good model for this, but that's not really a good excuse to keep writing new languages based on C.
"Part of how C++ is successful is that it retains C compatibility"
I think Objective C is a better object oriented C than C++. It's simpler, makes a syntactic distinction between message passing and "traditional" C, and has a more dynamic run time. I'm surprised no one else has brought up Objective C as a better solution to the "make C object oriented" problem.
The computer is actually has a von Neumann architecture, that is, they have code and data in the same address space.
To the degree that C represents this reality, it is through exploits: e.g. buffer overflows, overwriting the stack and return address, and executing arbitrary code supplied by attackers. C itself does not represent the reality very well, since it does not lend itself to writing code that writes code at runtime.
> C accurately models how the computer actually works
i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me.
so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)
I totally agree. C++ main strength lies in its "portable assembler" nature. However, C++ also is [quite a behemoth][1], while Lisp, Python and Haskell aren't so.
The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.
This is a disappointingly flamey article: roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days (which were admittedly horrible, but long since past). Most of the rest are from people who just skipped straight to Java, or who are so young that they never had to learn C++ at all.
The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++. Java is okay, but from its sketchy real-world performance, to its crappy generic programming support and poor ability to enforce such type-safety basics as const-correctness, I've never been impressed. Take the time to learn C++ for what it is, instead of "C with objects" and you'll find that it's far more elegant than the backlash would suggest.
I think that what most people really hate about C++ stems from the widespread use of legacy compilers that incorrectly implement the spec, or implement older versions of the spec. This problem exists for every programming language in the universe (e.g. Ruby 1.8.6 vs. Ruby 1.8.7 vs. Ruby 1.9), but since C++ is widely implemented by multiple vendors, the problem appears worse. If Python or Java were implemented by Microsoft and GNU and four other smaller companies, you'd see the same horrible compatibility problems with those languages, too.
The one point that I see throughout the article is that every programming shop uses it's own subset of C++. Based on coding conventions, library usage, and business domain I have seen how the C++ code used in different companies can look like a different programming language altogether.
My professional experience outside C++ is limited, but I had always assumed this was the same for other languages as well. Is C++ really that much of a different animal from other languages?
"If Python or Java were implemented by Microsoft and GNU and four other smaller companies, you'd see the same horrible compatibility problems with those languages, too."
There are a lot of Java implementations, and I am not aware of serious compatibility problems between them.
roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days
Zawinski and Thompson are good, but they are not 90% of Zawinski, Thompson, Bloch, Eich, Ingalls, Armstrong and Steele. You're completely misrepresenting the gist of the article.
The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++.
Oh please, don't start that flamewar with these kinds of uninformed, one sided utterances. Java performance has been more than fine for at least five years.
I would have to agree. I have no doubt that anyone in the early days of C++ probably had a real bad experience and was right to tell people not to use it at that time.
I personally still use C++ because of the libraries and tools. With Boost, Qt, WebKit, valgrind, gdb, and others I am simply too productive in C++.
If someone told me I could only use the c++ standard library and no other libraries I could probably switch languages pretty quick. I can only imagine what it must have been like before when you got nothing.
The problem with C++ is not just bad implementation. Nowadays we have excellent, standard-compliant compilers for C++ but there are still rough edges. For example, the amount of garbage you get from template errors. You can "learn" to live with that, but it is something broken in the language, which won't be solved quickly. The amount of care you need to to write correct exception-based programs is another. And the failure of exceptions on method signatures show how we should really avoid some of C++ features.
"Yet C++ is also frequently reviled both by those who never use and by those who use it all the time."
I was once listening to RMS speak at a conference. One guy got up and said that this was one of the n great talks he had been to.He mentioned that Stroustrup as another speaker who had impressed him upon which RMS said "You need to get your head checked".
Sometimes a great hacker community can help overcome the shortcomings of a language. Trevor Blackwell makes that point here: http://www.tlb.org/faq.html.
"Besides their intrinsic characteristics, languages define commmunities of programmers. You want to choose one that lets you communicate with good programmers, because you'll learn from them. They tend to prefer powerful languages like Python, Lisp, and C++. So for example, although Visual Basic is actually a powerful and complete language, few good programmers use it. C++, on the other hand, is a rather poorly designed language, but for historical reasons a lot of smart people use it so at least you'll be in good company."
> Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair.
I don't really see this. Most of C++'s complexity emerges naturally from three things:
1. Lack of GC.
2. Direct support for user-defined types on the stack.
3. The desire to implement every feature as efficiently as the corresponding C idiom.
There actually aren't very many controversial features in C++: multiple inheritance, operator overloading, templates, and exception handling are the ones that come to mind. With the exception of multiple inheritance, none of these is particularly heinous. Implementing them under the three restrictions above is where things get complicated.
Actually, the book "Design and Evolution of C++" shows Stroustrup saying "no" to quite a few features (e.g. named parameters). It would probably be more proper to say that Stroustrup didn't say "no" to enough people.
I see this claim made frequently, but Stroustrup talks about several features in Design & Evolution that were rejected. The committee requires implementations before accepting new features; they don't say "We like that idea" and include it without evidence that it's both possible and useful.
Well, he did say No to the concepts just few months ago, and that was one of more useful features proposed for C++0x. Though one has to admit it was an over-engineered, ugly monstrosity (surprise) and it was quite far from a simple and elegant idea that was long lobbied for by Alex Stepanov & Co.
There are parts of all languages that I find confusing, but I'm a little puzzled by the general criticism of C++ (e.g., the __getitem__ feature of Python seems to be similar in spirit to operator overloading. Do people criticize Python too?).
IMHO, C++ is an amazing extension to C which managed to increase productivity for those tasks for which C would have been the right choice (modulo non-standard compilers).
If I were writing a performance-critical system-level program today, using C++ would be no brainer. You can fake a lot of what C++ offers with macros and function pointers in C, but lose type-safety and/or performance. I am very thankful to all the people who have brought C++ to the state it is in today.
Its really fascinating to me. We had Lisp and then the road for many lead to C/C++, Java, and related and then we needed a way to express data in more human-readable form so some genius came up with XML. XML was to cumbersome (close tags, how attributes are expressed, etc.) and then JSON came into the picture. So all that to just come back to where we were in the first place.
Now I clearly understand what some of the veterans in "Coders at Work" really meant by "Very little progress, if any, has been made in the Programming space".
C++ is pretty awful to develop in, especially compared to many other languages. Some of these issues have to do with poorly designed features in the core language (templates), static variable instantiation, no good way for declaring complex data structures in the language (a'la JSON), multiple inheritance, etc.
But this isn't just a problem with the core language itself, but with the compilation model and linkage model - and the compilers and linkers. You need include guards on the top of your header files to make sure the code doesn't get re-included. You have to aggressively forward declare to work around declaration dependencies. And you have to trim the files that you include to keep compile times under control, because here's the fun thing about C++: For every .cpp file in your project, you will end up reading in and parsing the same damn header files again and again. In a large project, that might mean recompiling the same header files 1000s of times. Precompiled headers aren't a good solution, either - because when you have to touch the header, you pay a huge cost in recompiling the PCH.
In every other language I've used, I haven't had to worry about carefully restructuring code (sometimes at a cost in performance) to reduce compile times - because the core include and dependency mechanism sucks so badly.
Finally, C++ as a language is very poorly extensible. By this, I mean in compared to languages like LISP (with macros), or Ruby / Scala, which both make writing DSLs very easy. This is especially unfortunate, given that is so heavily used in a lot of very specific domains. And don't get me started on templates - I couldn't dream up a more backwards and awkward way of doing generics if I tried.
I think it's a very good article detailing the various flaws of C++; I particularly have problems with the complexity of the languages making it very difficult for compiler writers to generate usable error messages (not only true for gcc as mentioned in the article, but Microsofts C++ compiler generates many unusable error messages, too! [At least it did in 2004, never touched it again...])
the point about everyone making their own sub-language is exactly right. In fact, I've heard programmers say that's exactly what they love about it.
Problem is, every shop is inventing their own subculture. When programmers who haven't worked together look at each other's C++, they're basically learning a new language.
I do think this has changed a bit in the last few years. The whole 'design pattern' meme exists primarily to create nexuses of style that programmers can gravitate to. It just seems like such a slow way home, especially in comparison to a language like Python, which goes out of its way to restrict the number of ways you can skin the cat.
Has any serious programmer ever looked at a Python file and said "wtf?" for more than a minute or two? And, has any experienced programmer not had the experience of looking at a new batch of C++ (say at a new job) and thought to him/herself, jeez, this is going to be a lot of work just to understand the basics of what they're doing?
Of course it's going to be more convoluted then newer languages like Java: Java doesn't have to maintain backwards compatibility with a 35+ year old programming language. That's just stating the obvious.
Yet for some reason people still use it. The question is 'why'. For many cases (not all though), I think the reason is largely just institutional inertia - you stick with the devil you know rather than the devil you don't know.
Have there been experiments with creating a pre-compiler that checked that you were using a subset of C++? What downsides would this have (other than longer compile time)?
When I program in C++ (and sometimes you have to) there are features that I'll avoid like the plague, once bitten, twice shy.
In fact, my subset of C++ was usually try to stay as close as you can to C and use C++ when you have to. That seemed to be a pretty safe route.
Most of my C++ stuff was using Borland C++ Builder or Microsoft visual C++, I'm happy to say I no longer have to support software for the windows platform, so no more C++ for me.
It's the only language I really feel comfortable programming in, and everything else seems
1) slow or
2) alien
in comparison.
I'm digging scala's design, but have yet to really compare it for number crunching, and big library building.
By the way, the article didn't really dig into any specifics besides saying there was feature bloat in C++. Which languages don't have feature bloat? How much use can I get out of them?
How could people complain on c++ when so many daily useful tools were written in it? Even their beloved JVM is a mere C++ program. Consider very successful and really cross-platform Webkit, V8, Mozilla's Geeko and so on. And there are thousands successful proprietary projects like Informix and even this popular MySQL.
If Google, Mozilla and many others can productively use C++ why other people can't? They even published guidelines how to use stable and portable subsets of language.
Argh. Not a very useful article. Start with an observation: "Everyone hates C++, and yet it is really widely used. That's odd." Next, 10 paragraphs of people hating on C++. End with: actually wait, no ending.
[+] [-] Oxryly|16 years ago|reply
And then C++ implements several programming paradigms (object oriented, generic, etc) without compromising that machine model.
Plus Bjarne was truly correct when he said: "there are languages people complain about, and there are languages nobody uses."
[+] [-] raganwald|16 years ago|reply
I think this is very true, what it says literally is that popularity and attracting ire are correlated.
However, my interpretation is that the reason why this is true is that (1) all languages involve design trade-offs, (2) every trade-off pisses someone off for at least a moment, and (3) popularity attracts eyeballs, therefore more popular languages have more people pissed off.
I am not suggesting you say this, but I have heard the (strawman?) argument that it is possible to design a nice, pure language that is above reproach but that it can't be popular, and thus his quote expresses the thought that there is an inverse relationship between elegance and popularity. I don't think this is the case.
[+] [-] dschobel|16 years ago|reply
For my money, developers are better off knowing two tools (c + some very high level language) rather than the spork which is C++.
[+] [-] gchpaco|16 years ago|reply
[+] [-] jimbokun|16 years ago|reply
I think Objective C is a better object oriented C than C++. It's simpler, makes a syntactic distinction between message passing and "traditional" C, and has a more dynamic run time. I'm surprised no one else has brought up Objective C as a better solution to the "make C object oriented" problem.
[+] [-] barrkel|16 years ago|reply
To the degree that C represents this reality, it is through exploits: e.g. buffer overflows, overwriting the stack and return address, and executing arbitrary code supplied by attackers. C itself does not represent the reality very well, since it does not lend itself to writing code that writes code at runtime.
[+] [-] monos|16 years ago|reply
i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me.
so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)
[+] [-] loup-vaillant|16 years ago|reply
[1]: http://yosefk.com/c++fqa/
The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.
[+] [-] amalcon|16 years ago|reply
C++ is C, except that it doesn't completely suck for higher-level projects.
[+] [-] slpsys|16 years ago|reply
[+] [-] timr|16 years ago|reply
The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++. Java is okay, but from its sketchy real-world performance, to its crappy generic programming support and poor ability to enforce such type-safety basics as const-correctness, I've never been impressed. Take the time to learn C++ for what it is, instead of "C with objects" and you'll find that it's far more elegant than the backlash would suggest.
I think that what most people really hate about C++ stems from the widespread use of legacy compilers that incorrectly implement the spec, or implement older versions of the spec. This problem exists for every programming language in the universe (e.g. Ruby 1.8.6 vs. Ruby 1.8.7 vs. Ruby 1.9), but since C++ is widely implemented by multiple vendors, the problem appears worse. If Python or Java were implemented by Microsoft and GNU and four other smaller companies, you'd see the same horrible compatibility problems with those languages, too.
[+] [-] jobu|16 years ago|reply
My professional experience outside C++ is limited, but I had always assumed this was the same for other languages as well. Is C++ really that much of a different animal from other languages?
[+] [-] jimbokun|16 years ago|reply
There are a lot of Java implementations, and I am not aware of serious compatibility problems between them.
[+] [-] Confusion|16 years ago|reply
Zawinski and Thompson are good, but they are not 90% of Zawinski, Thompson, Bloch, Eich, Ingalls, Armstrong and Steele. You're completely misrepresenting the gist of the article.
The comments that really drop my jaw are the people who seem to hold up Java as a "better" C++.
http://www.paulgraham.com/icad.html
but from its sketchy real-world performance
Oh please, don't start that flamewar with these kinds of uninformed, one sided utterances. Java performance has been more than fine for at least five years.
[+] [-] icefox|16 years ago|reply
I personally still use C++ because of the libraries and tools. With Boost, Qt, WebKit, valgrind, gdb, and others I am simply too productive in C++.
If someone told me I could only use the c++ standard library and no other libraries I could probably switch languages pretty quick. I can only imagine what it must have been like before when you got nothing.
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] coliveira|16 years ago|reply
[+] [-] rams|16 years ago|reply
I was once listening to RMS speak at a conference. One guy got up and said that this was one of the n great talks he had been to.He mentioned that Stroustrup as another speaker who had impressed him upon which RMS said "You need to get your head checked".
Sometimes a great hacker community can help overcome the shortcomings of a language. Trevor Blackwell makes that point here: http://www.tlb.org/faq.html.
"Besides their intrinsic characteristics, languages define commmunities of programmers. You want to choose one that lets you communicate with good programmers, because you'll learn from them. They tend to prefer powerful languages like Python, Lisp, and C++. So for example, although Visual Basic is actually a powerful and complete language, few good programmers use it. C++, on the other hand, is a rather poorly designed language, but for historical reasons a lot of smart people use it so at least you'll be in good company."
[+] [-] jacquesm|16 years ago|reply
> And he said “no” to no one.
And that is the core of the problem.
[+] [-] dkarl|16 years ago|reply
I don't really see this. Most of C++'s complexity emerges naturally from three things:
1. Lack of GC.
2. Direct support for user-defined types on the stack.
3. The desire to implement every feature as efficiently as the corresponding C idiom.
There actually aren't very many controversial features in C++: multiple inheritance, operator overloading, templates, and exception handling are the ones that come to mind. With the exception of multiple inheritance, none of these is particularly heinous. Implementing them under the three restrictions above is where things get complicated.
[+] [-] cbeust|16 years ago|reply
[+] [-] scott_s|16 years ago|reply
[+] [-] huhtenberg|16 years ago|reply
[+] [-] psranga|16 years ago|reply
IMHO, C++ is an amazing extension to C which managed to increase productivity for those tasks for which C would have been the right choice (modulo non-standard compilers).
If I were writing a performance-critical system-level program today, using C++ would be no brainer. You can fake a lot of what C++ offers with macros and function pointers in C, but lose type-safety and/or performance. I am very thankful to all the people who have brought C++ to the state it is in today.
[+] [-] alrex021|16 years ago|reply
Now I clearly understand what some of the veterans in "Coders at Work" really meant by "Very little progress, if any, has been made in the Programming space".
[+] [-] haberman|16 years ago|reply
[+] [-] sshumaker|16 years ago|reply
But this isn't just a problem with the core language itself, but with the compilation model and linkage model - and the compilers and linkers. You need include guards on the top of your header files to make sure the code doesn't get re-included. You have to aggressively forward declare to work around declaration dependencies. And you have to trim the files that you include to keep compile times under control, because here's the fun thing about C++: For every .cpp file in your project, you will end up reading in and parsing the same damn header files again and again. In a large project, that might mean recompiling the same header files 1000s of times. Precompiled headers aren't a good solution, either - because when you have to touch the header, you pay a huge cost in recompiling the PCH.
In every other language I've used, I haven't had to worry about carefully restructuring code (sometimes at a cost in performance) to reduce compile times - because the core include and dependency mechanism sucks so badly.
Finally, C++ as a language is very poorly extensible. By this, I mean in compared to languages like LISP (with macros), or Ruby / Scala, which both make writing DSLs very easy. This is especially unfortunate, given that is so heavily used in a lot of very specific domains. And don't get me started on templates - I couldn't dream up a more backwards and awkward way of doing generics if I tried.
[+] [-] prakash|16 years ago|reply
[+] [-] sb|16 years ago|reply
[+] [-] danbmil99|16 years ago|reply
Problem is, every shop is inventing their own subculture. When programmers who haven't worked together look at each other's C++, they're basically learning a new language.
I do think this has changed a bit in the last few years. The whole 'design pattern' meme exists primarily to create nexuses of style that programmers can gravitate to. It just seems like such a slow way home, especially in comparison to a language like Python, which goes out of its way to restrict the number of ways you can skin the cat.
Has any serious programmer ever looked at a Python file and said "wtf?" for more than a minute or two? And, has any experienced programmer not had the experience of looking at a new batch of C++ (say at a new job) and thought to him/herself, jeez, this is going to be a lot of work just to understand the basics of what they're doing?
[+] [-] tptacek|16 years ago|reply
I think the book might have worked better if it was organized topically, instead of by person.
[+] [-] Jeema|16 years ago|reply
Yet for some reason people still use it. The question is 'why'. For many cases (not all though), I think the reason is largely just institutional inertia - you stick with the devil you know rather than the devil you don't know.
[+] [-] cturner|16 years ago|reply
[+] [-] jacquesm|16 years ago|reply
When I program in C++ (and sometimes you have to) there are features that I'll avoid like the plague, once bitten, twice shy.
In fact, my subset of C++ was usually try to stay as close as you can to C and use C++ when you have to. That seemed to be a pretty safe route.
Most of my C++ stuff was using Borland C++ Builder or Microsoft visual C++, I'm happy to say I no longer have to support software for the windows platform, so no more C++ for me.
[+] [-] jacquesm|16 years ago|reply
http://google-styleguide.googlecode.com/svn/trunk/cpplint/cp...
[+] [-] messel|16 years ago|reply
I'm digging scala's design, but have yet to really compare it for number crunching, and big library building.
By the way, the article didn't really dig into any specifics besides saying there was feature bloat in C++. Which languages don't have feature bloat? How much use can I get out of them?
[+] [-] c00p3r|16 years ago|reply
If Google, Mozilla and many others can productively use C++ why other people can't? They even published guidelines how to use stable and portable subsets of language.
[+] [-] known|16 years ago|reply
[+] [-] nearestneighbor|16 years ago|reply
[+] [-] aboodman|16 years ago|reply
[+] [-] jacquesm|16 years ago|reply
Also, they make fairly specific criticisms, and they have a track record of being right about such things.
Java seems to be the C++ replacement of the future, with C# pulling the other way.