Quote:
the less hidden code the better. And on that parameter alone C wins.
Tell me which is slower, I dare you:
a = b;//ormemcpy(&x,&y,z);
Go ahead, I'll wait.
The problem with your argument is that you're basing your attack on "C++" on a lack of context, but apparently allowing for that same context to be available in the case of "C." In the C++ case you're basically assuming that given the assignment (or in general any other use of an operator or function call, et cetera) you don't have any idea what the types are or what their values are, and so you can't tell if operator overloading is involved or what the cost of the operation will be. But without that information in C, you have the same problem - the size of the type would be an issue in C, had I used a sizeof and not a third variable, but the value of the third variable is still a "potential unknown." If you make you argument with a level playing field, it doesn't hold up well.
I can pass or copy data efficiently or inefficiently in C, just as easily as in C++. It just looks different. I find it very difficult to believe that somebody who knows both languages to a suitable degree of competency doesn't know what to look for in terms of performance pitfalls in either language. Most of it simply good software engineering; being aware of what that is and reflecting it in the idioms and syntax of your chosen medium.
Quote:
The big difference is that you know full well when you activate a function, but its harder knowing about operator overloading, hidden constructors, polymorphic methods and invisible variables.
Knowing that operator overloading exists in C++, and is something to watch out for, is part of knowing C++. Anybody who isn't aware of these issues, I would happily fire.
Now, overloading is prone to...abuse. Redefinition of operator+ to subtract your FixedPoint instances, for example. I think, however, that we can both agree this falls into the category of "stupid" and anybody who would seriously consider this for production code should, similarly, be fired. It's the same thing you said regarding functions: it's not a matter of a broken hard drive; nobody in practice would be that idiotic, at least not on purpose.
And besides, what does it matter? Okay, so a function call is virtual. And? Do you think that's a performance bottleneck?
Did you profile it? The features in question are higher level language features design to increase productivity of the developer. Yes, they may from time to time have a performance impact.
That does not make them wrong. Using them incorrectly makes them wrong, and any feature in any language can be abused in such a fashion. Prematurely worrying about expensive copies and all that other early, unguided optimization is frequently a productivity killer.
And let's not even get into all the tools available in modern development environments to detect and track most of these issues, to navigate and profile and sanity check code, et cetera.