In some situations exception handling must be abandoned for less subtle error handling techniques.
[..] One may indeed wonder why nobody in the vast software industry has undertaken the task proposed by you: Defining a safe subset of C++. I can figure out two reasons: (1) The software world is eager for "more powerful" languages, but not for restrictive subsets. And (2), such attempts are doomed to fail just like attempts to strengthen the structure of a house built on sand. There are things that you simply cannot add as an afterthought [..]
[..] 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. [..]
[..] 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. [..]
[..] Sometimes I do write C++ instead of C. C++ I think is basically too big a language, although there's a reason for almost everything that's in it. When I write a C program of any size, I probably will wind-up using 75, 80, 90% of the language features. In other words, most of the language is useful in almost any kind of program. By contrast, if I write in C++ I probably don't use even 10% of the language, and in fact the other 90% I don't think I understand. In that sense I would argue that C++ is too big, but C++ does give you may of the things that you need to write big programs: it does really make it possible for you to create objects, to protect the internal representation of information so that it presents a nice facade that you can't look behind. C++ has an enormous amount of mechanism that I think is very useful, and that C doesn't give you. [..]
[..] 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. [..]
[..] 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. [..]
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. [..]
[..] Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp. [..]
Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, "OK, we'll do them both". So the language is too baroque for my taste.
PL/I and Ada started out with all the bloat, were very daunting languages, and got bad reputations (deservedly). C++ has shown that if you slowly bloat up a language over a period of years, people don't seem to mind as much.
[..] C++ is a difficult language in which there may be a very fine line between a feature and a bug. This places a large responsibility upon the programmer. [..]
C++ is already too large and complicated for our taste.
There are 26 items under the index entry for ambiguity in the Annotated C++ Reference Manual.
C++ is the best example of second-system effect since OS/360.
C++ is the only current language making COBOL look good.
C++ is an insult to the human brain.
It has been discovered that C++ provides a remarkable facility for concealing the trivial details of a program - such as where its bugs are.
When your hammer is C++, everything begins to look like a thumb.
c++; /* this makes c bigger but returns the old value */