In an environment where every byte and cycle counts I'd be using C. C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.).
If you can live with enabled exception handling (which is a performance toll) then some additional object meta data shouldn't be a problem.
> C++ has too much stuff going on behind the scenes. (Like hidden object copies, potentially bloated operators, etc.).
The thing is, C++ is usually good about not charging you for features you don't use - and with the reasonably good debugging and profiling tools, most of the problems you mention above are fixable to get performance that is close (or equal) to C, with maybe better maintainability.
To pick a not-so-random example of something that's difficult to implement in C as safely as in C++, see expression templates[1]. I'd be interested in something similar to what eigen does written in C. (Of course, the last time I did this minibenchmark, so-and-so's lapack library was still slightly faster than eigen :)
The bottom-line, perhaps, is that if I'm writing a library, I'd do it in C simply because it's self-contained and has a nicely limited scope, and as a bonus is usable from oh-so-many other languages. If I'm writing an application that really, really requires serious performance, I'd prefer to use C++.
If you can live with enabled exception handling (which is a performance toll) then some additional object meta data shouldn't be a problem.