You have to be a different kind of person to love C++. It is a really interesting example of how a well-meant idea went wrong, because Bjarne Stroustrup was not trying to do what he has been criticized for. His idea was that first, it might be useful if you did to C what Simula did to Algol, which is basically act as a preprocessor for a different kind of architectural template for programming. It was basically for super-good programmers who are supposed to subclass everything, including the storage allocator, before they did anything serious. The result, of course, was that most programmers did not subclass much. So the people I know who like C++ and have done good things in C++ have been serious iron-men who have basically taken it for what it is, which is a kind of macroprocessor. I grew up with macro systems in the early '60s, and you have to do a lot of work to make them work for you - otherwise, they kill you.
-Alan Kay
As for C++ - well, it reminds me of the Soviet-era labor joke: "They pretend to pay us, and we pretend to work." C++ pretends to provide an object-oriented data model, C++ programmers pretend to respect it, and everyone pretends that the code will work. The actual data model of C++ is exactly that of C, a single two-dimensional array of bits, eight by four billion, and all the syntactic sugar of C++ fundamentally cannot mask the gaping holes in its object model left by the cast operator and unconstrained address arithmetic.
-Guy Steele
The languages that succeed are very pragmatic, and are very often fairly dirty because they try to solve real problems. C++ is a great example of a language that in many ways has serious flaws. One of the flaws is that it tried very hard to be compatible with C: compatible at the object level, compatible very closely at the source level. Because of this there are places where there's something ugly in the language, weird syntactic problems, strange semantic behaviors. In one sense this is bad, and nobody should ever do that, but one of the reasons that C++ succeeded was precisely that it was compatible with C, it was able to use the C libraries, it was usable by the base of existing C programmers, and therefore people could back into it and use it fairly effectively without having to buy into a whole new way of doing business. And this is not the case for ML, which was being done at about the same time and, at least partly, in almost the same place, but which took a very different view of the world. As a pragmatic thing, C++ is extremely successful but it paid a certain price by being compatible with the previous language.
-Brian Kernighan
Name:
Anonymous2012-07-16 19:16
>>16
why not? please provide at least 30 good arguments
Name:
Anonymous2012-07-16 19:19
I really like C++. I was instantly attracted to it back in 1986, and created the first native C++ compiler (Zortech C++). Over the years since, C++ has grown by layering on needed features without disturbing backwards compatibility. Often this results in some very strange rules and surprising corner cases. In the meantime, the rest of the programming world certainly has grown, too, with features and paradigms with proven productivity. At some point, it just makes sense to look at where we are, and try to design a language that gets there in a straight line, rather than try to be compatible with obsolete decisions made 20 or 30 years ago. C++ isn't hard to parse because it requires arbitrary lookahead; that's an easy problem to solve. It's hard to parse because a particular sequence of tokens can produce multiple totally different parse trees, depending on what some of the symbols are declared as. Even worse, many of those symbols aren't known at parse time, because they aren't declared yet. So it has to be parsed into some indeterminate state that gets "fixed" later. This issue makes it impossible to correctly parse C++ code without building most of a C++ compiler front end, including all the hard stuff. It's further complicated by the preprocessor - unless the parser has full implementation of the preprocessor, and includes all the #includes and command line #defines, it cannot successfully parse an arbitrary C++ source file. This cripples the utility of source formatters, analyzers, syntax directed editors, documentation generators, source code instrumentation tools, etc. A lot has been learned about programming since C++ was developed. Much of this has been folded in C++ as layers on top of the existing structure, to maintain backwards compatibility. It's like a farmhouse that has been added on to by successive generations, each trying to modernize it and adapting it to their particular needs. At some point, with a redesign, you can achieve what is needed directly.
-Walter Bright
Q: Every language has its flaws. What are the three things you dislike most strongly in C++?
I'd like to answer this question with "complexity, complexity, complexity!", but naming the same thing three times is cheating. Still, I think that C++'s greatest weakness is complexity. For almost every rule in C++, there are exceptions, and often there are exceptions to the exceptions. For example, const objects can't be modified, unless you cast away their constness, in which case they can, unless they were originally defined to be const, in which case the attempted modifications yield undefined behavior. As another example, names in base classes are visible in derived classes, unless the base class is instantiated from a template, in which case they're not, unless the derived class has employed a using declaration for them, in which case they are. Such complexity affects more than just people who write programs in C++. It also affects people who want to write tools that analyze C++ programs. One of the reasons why there is a relative dearth of tools such as refactoring browsers for C++ is that C++ is just so darned complicated. A related aspect of C++ I dislike has to do with what I perceive to be an attitude on the part of the standardization committee that such complexity is not a problem. I suspect that many members of the committee would object to my characterizing their attitude that way, but I'm talking only about my perception of their attitude. I know that the people on the committee work hard to make C++ as good as it can be. I also know that there are proposals before the committee whose goal is to simplify C++. Still, my impression is that the committee as a whole is unsympathetic to arguments that C++ has become too complex, and I find that frustrating.
-Scott Meyers
Name:
Anonymous2012-07-16 20:18
``C++ is to C what lung cancer is to lung.''
Name:
Anonymous2012-07-16 21:47
C++ is better than D or Ada because of widespread support. Good luck getting that C++ graphics library or linear algebra library working with D. And good luck getting Intel to make an optimizing D compiler.
>>22
Im going to re-quote part of Scott Meyer's above quote since its worth repeating: One of the reasons why there is a relative dearth of tools such as refactoring browsers for C++ is that C++ is just so darned complicated.
The fact is that there is no real support for C++ because it is such a shitty tacked together language that making coherent tools for it is impossible. Any API out there can be used by D. D has OpenGL bindings which is really all you need to do serious graphics programming. Everyone rolls their own math libraries for DirectX and OpenGL, math is not part of either. No one uses intel compilers except for private for commercial software, that would be suicide to make CPU brand dependent software. The fact that LLVM has a D compiler is really the best possible compiler structure on which to build on. C++'s reign of terror on software development is soon to end.