There was a time when I made most of my income debugging other peoples programs, call it 'troubleshooter' or something like that.

It gives you an excellent overview of the various ways in which things can go wrong, and C++ figured quite prominently in the 'gotcha' department.

C has it's share of issues, double frees, failure to initialize (but most compilers catch that one nowadays), and stale pointers. With a good discipline you can work around those.

C++ can obscure the bugs in such a way that it takes you a long long time before you can 'nail' them. The biggest problem I have with the language is that the code tends to obscure what is going on at the machine level.

I guess that's a 'feature' too, but I prefer to have a more direct correspondence between program code and what goes on below the surface. That's a problem with OO in general by the way, and I think that this is part of what makes software so terribly inefficient these days.

Gigabytes of ram are barely enough to accomodate a single user os, it's really pretty weird.

Point taken; I have never had to deal with poorly written code that makes casual use of obscure C++ features. My shop tends to be very careful with the sharp edges, so you don't have to have guru knowledge to skim our code and see what's happening. All potential "gotchas" are commented, just like any other difficult code. Obviously the standards you can realistically demand from your coworkers go out the window when you're dealing with legacy code.

"The biggest problem I have with the language is that the code tends to obscure what is going on at the machine level."

Which totally defeats the purpose of being backward compatible with C.

I think that basing it off C was a quick way to get widespread acceptance though. It succeeded in that respect.

Yep. If you had a C program you were automatically already using C++. You could just suddenly start to use the extra features where you wanted them. For that it was great.

If it had been D instead, an actual new version of C designed to incorporate new features, instead of C++, additional features on top of C, it probably would be less reviled but there would have been a lot more resistance to adoption.

Please, use a precise term if you talk about multiple inheritance, even though in this case it is clear that C++-MI is the multiple inheritance is meant.

In general, there is at least the linearizing (Common lisp) multiple inheritance with a well defined method lookup semantics (even though there are good ways to shoot one into the foot there), and the C++-local-hackity-multiple inheritance (where the programmer has to resolve lookup ambiguities, resulting in unpredictable semantics). And this even avoids the discussions of traits, mixins and such.

Different problem, different constraints, different solution. And, inevitably, just different ways to shoot yourself in the foot. Please explain how Common Lisp multiple inheritance relates to the question at hand, which is whether the complexity of C++ came from undisciplined language design or was inevitable given the design constraints of the language.

The distinction matters, because the multiple inheritance in common lisp (and other linearizing languages) is a lot saner and easier to use than multiple inheritance where the programmer has to define the method lookup sequence, which in term implies that multiple inheritance in itself is not the sole cause of complexity in this context, but rather the implementation of multiple inheritance in the given language (C++).

CLOS method dispatch does not meet the design criteria of C++. It uses runtime information about inheritance relationships, for example.

Also, note that there is also a semantic difference here between C++ (and Java) and most other languages. In C++ multiple inheritance, if classes A and B define method foo, and A and B have no inheritance relationship, then A::foo and B::foo are entirely unrelated methods -- just as if they were named A::foo and B::bar. The fact that they have the same name does not automatically create a relationship between them, as it would in CLOS or in duck-typed languages like Python. That means that a call to foo in a class that inherits from A and B is just as ambiguous as if the programmer had typed "foo, or maybe bar." This unrelatedness is inherent to C++'s type system. It would make no sense to a C++ programmer to treat A::foo and B::foo as being alternative dispatch targets for the same method call.

Even if you allow the compiler to gloss over this unrelatedness, I still think it is a matter of taste whether it is simpler to require programmer disambiguation or to have a well-defined algorithm for resolving ambiguous names. C++ usually takes heat for providing powerful more-than-meets-the-eye mechanisms that allow programmers to "hide" program semantics inside language features. Here C++ takes the opposite approach and requires the programmer to explicitly resolve ambiguous names, and it takes heat from a CLOS programmer, who could write an entire operating system using a single family of generic functions all having the same name ;-) Damned if you do, damned if you don't.

> who could write an entire operating system using a single family of generic functions all having the same name ;-)

I sense an upcoming challenge! ;)

Operator overloading in C++ is indeed more complex than it should be, thanks in part to the three different ways to pass paremeters (references, pointers, and values). It's definitely more straightforward in languages like C# or Python (or, well, just about anything else) that don't have these explicit distinctions.

The distinction between pointers and values (and the ability to treat pointers as values) is necessary for many applications of C++, so that complexity _should_ indeed be in the language. You may be right that the distinction between pointers and references is gratuitous. Ordinarily, one defines an overloaded operator using reference arguments (never pointers; only values if you're doing performance microoptimizations, i.e., only for a handful of carefully inspected types) and dereferences pointers before applying the operator, so it doesn't really matter unless code in some other module is overloading operators for your types. That's a bizarre circumstance that never happens in practice.

"that complexity _should_ indeed be in the language"

Oh, absolutely. I just meant that it adds some incidental complexity to operator overloading that doesn't exist in other languages.