I can think of thousands of reasons to use C. C is much like learning to drive a stickshift.
C++ is an utterly broken language. It's just an exercise in bad compiler errors, strange and inconsistent language constructs, and strange conventions and boilerplate you need to follow to produce correct code.
(http://amalp.blogspot.com/2007/10/what-is-protected-abstract...)
That's a troll example, designed to be maximally unreadable. The first four words refer to the class, and the last four refer to the function; moreover, one of the words in the former is implied by the latter. So, when you munge it all together, and include more words than necessary, then yeah, it sounds complicated. Thing is, nobody actually does that, unless they're writing articles that bash C++. (In this case, you'd say that you have a protected base class, whose destructor is pure virtual and private. The fact that the base class is declared "virtual" is of no consequence to the destructor.)
There's no doubt that C++ is a complicated language, but if you're going to criticize it, at least reach for something that's a bit more insightful than "you can obfuscate your code!"
And why is the keyword 'virtual' even necessary? Surely all methods should be virtual by default (and the compiler ought to be able to replace virtual calls with direct calls based on the type information). Can anyone cite an example of where you'd actually want to call different methods depending on whether you're using a base or a derived pointer?
I think trying to bolt an OO model onto C while retaining 100% source compatability was an interesting idea, but it turned out to be a bad one in the long run. 90% of the complexity in C++ you don't actually need, you can get by just fine with C, and you have the added bonus that you can hold pretty much the entire language and a significant portion of the standard library in your head the whole time whilst you code, which I never managed to do with C++.
Admittedly, my experience is probably informed by having to maintain some seriously hideous C++ code over the last 10 years.
So, there, C++ is a complicated language. Some might say it's too complicated, but I guess everyone has to do their own cost/benefit analysis on that.
Is that better?
And how is the compiler supposed to determine the (possibly dynamic) type of an object at compile time, in order to determine when to make the call statically?
If you declare a method virtual, you're telling the compiler to use late binding. If you don't, you're telling the compiler to use early binding. You always know what you're going to get. That's why the keyword is there -- so you don't have to guess.
"Can anyone cite an example of where you'd actually want to call different methods depending on whether you're using a base or a derived pointer?"
Not sure what you're asking here. Are you talking about the ability to hide a base class method with a derived class method? It's not really considered a good idea to do such a thing (see: http://www.parashift.com/c++-faq-lite/strange-inheritance.ht...), but it's an inevitable consequence of mixing early- and late-binding features in the same language.
Yes. It sounds like we agree that overriding a non-virtual method is a bad idea, and i think "mixing early- and late-binding" probably captures it quite well. The C++ compiler makes the programmer decide whether to use early or late binding, and handle the consequences.
In some other languages (let's say Self, for example), the distinction between early and late binding is handled by the compiler, so it's invisible at source level, and all methods are (implicitly) virtual unless the compiler can prove that a static call is safe, in which case it can inline the call. That means that the "early-binding conflict" situation can't arise in a language like Self.
Oh, I don't know, Objective-C seems to do a reasonable job of it. C++ just took the wrong object model...
* No compile time encapsulation
* Outstandingly complicated grammar
* No way to locate definitions
* No run time encapsulation
* No binary implementation rules
* No reflection
* Very complicated type system
* Very complicated type-based binding rules
* Defective operator overloading
* Defective exceptions
* Duplicate facilities
* No high-level built-in types
* Manual memory management
* Defective metaprogramming facilities
* Unhelpful standard library
* Defective inlining
* Implicitly called & generated functions
If we eliminate those, the list reduces down to about eight objective criticisms, of which several are just wrong (No high-level types? Bzzt. The STL is part of the language), and others that are minor variants of the same complaint (that it's not a dynamic language).
I've posted a short outline to provide a context for the link. It is easy to read and the critique it provides is worth reading by any C++ programmer.
Do not believe my words, just try to read it and see for yourself.
EDIT: I want to make it clear. C++ is a valuable tool for some tasks. But.. No size fits all. And knowing the weaknesses of the tool at hand does not hurt either.
The "high-level" criticism, in particular, quickly devolves into a complaint about the complexity of template generics, and how the error messages emitted by current C++ compilers are cryptic. It's unclear what his solution to the problem would be, short of a fully dynamic type system.