There are other penalties which people who write C++ are oblivious to. For example, switching the class of an established object in runtime:
Suppose you have two compatible class layouts (same field order and types, different methods). When you implement dispatch yourself, switching the behavior is a simple matter of replacing the vtbl pointer from one class to the other (I'm not sure Linux VFS does this, but it's common enough in C object systems).
Whereas if you use C++, the standard solution is to break this into a dataless "strategy" object (which can be changed independently of the data) and a data object which contains the state. If you never had the luxury of doing something like "if (obj->class == Living) obj->class = Zombie", you don't miss it, but it doesn't mean you're not missing out on some flexibility.
> Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.
Furthermore, just because you are doing object-oriented programming doesn't mean it is useful. (And a purist would say, just because you are doing programming, doesn't meant it is useful)
> Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.
I've switched to C++ in 1993 and back to C in 2004 when compile times with boost started to measure on a geological time scale and single error messages spilled onto my 2nd screen -- and haven't looked back. When a write GUIs, I do use FLTK which is C++ (very effective, but not idiomatic), because I haven't seen a GUI toolkit as good that's native C -- but other than that, I don't miss anything, and I'm not less productive.
C++, the language, has a lot of useful tools, but C++, the ecosystem, guarantees that in any nontrivial project you'll be thrown into the tarpit. In my experience, the overall effect of C++ on a project is negative. YMMV.
