I still don't get your logic. Your example has nothing to do with "C" as defined by standard. I have no reason to believe that one, using 'gcc' suite, can't use exactly the same built-in SIMD primitives for C++.

C++ by itself does not imply overhead. With great (though not absolute) precision one can say that C++ is simply a superset of "C".

If you think "C" is faster, take the real differences between C++ and C99, i.e. use features that are present in C99, but not in C++, and using those features write C99 code which, you think, is better than similar code in C++.

Only that would be a good starting point to show performance advantages of C99 over C++.

...

Again, I do not like C++, I find it convoluted, tangled and illogical. But I'm trying to be objective.

Generalizations are very difficult to make about the "relative execution time of" any program in any language, because the nature of the program, and of the specific source code that has been developed (said source code being, of course, very language-dependent) has much more influence than the language. Contrary to the popular opinions being expressed here, IMHO "C" is not used or not-used because it is "faster" ... it is used either because of history, or because of expressiveness.

The gcc compiler suite supports a half-dozen different languages using virtually the same "back end." Your source-code is translated to an intermediate format which is, from that point forward, language-independent.

A "C" program "assumes the co-existence of very little." In fact, say in the case of the Linux kernel, a program can be written which "assumes the co-existence of" absolutely nothing other than itself. The language permits the programmer to work at a somewhat-high level of abstraction or to "get down and dirty with the hardware," and everything in-between, and in fact you see the Linux kernel doing precisely that ... for over 21 radically-different hardware target platforms. When you need to do "that job," the C language is a tool designed to perform "that job."

Programming languages are "tools for the job." Nothing more or less. You have "an embarrassment of riches" to choose from, every one of them free.
Do not choose poorly.

"Why is C still out there?" Because very sound reasons for selecting it continue to exist ... and because literally hundreds of millions of lines of mission-critical software, still happily in service (including "Linux itself"), has been written using it ... and because it was and is "a wise choice" in those contexts. (It was, of course, specifically built to be so.)

My experience indicates otherwise. In expert hands, the extra cost is just the dependency on (a specific version of) libstdc++. (Note that all programs, including C++ ones, depend on libc in Linux; either at link time or at run time. C++ binaries are larger, especially since every compiler version tends to produce a new non-downwards-compatible libstdc++.)

Before this thread, I believed it would be difficult to avoid using virtual methods and exceptions (which do have overhead); I thought the standard C++ library itself uses these features internally. I guess I was wrong, and the only unavoidable overhead is the standard C++ library dependency.

I'm not sure at which point g++ links in the standard C++ library, though. Both gcc -std=c99 and g++ -std=c++03 seem to produce the same binary when fed a C source file.

Syntax yes, but languages no. They are governed by different standards. Although almost all of C code compiles as C++, it does not necessarily have the same semantics. Many are the same, but some important ones differ.

Consider Kahan summation algorithm:
Traditionally, this code would have to be compiled without optimization, or some specific compiler settings, or the compiler would optimize it away yielding incorrect results.

In C99, the casting rules state that the compiler must retain the precision of a cast expression; optimization may not lead to a case where the cast expression is evaluated at a higher precision, even implicitly. In other words, given
a C99 compiler will happily optimize and still always produce correct code. As far as I can tell -- please correct me if I'm wrong --, the C++ standard only defines the results if the cast type differs: a C++ compiler may optimize the err factor completely out, yielding different results.

I think g++ does apply the same casting rules for C++. I believe Intel Compiler Collection does not, but I'm too lazy to check (I do not have it installed at home right now), so I might well be wrong.

In practice, I think most compilers nowadays apply optimization strategies that do not affect the result, but I do not see anything in the standards that would require them to do so, but which is sensible in practice because otherwise a lot of computational code would have to be compiled without optimizations to get the correct numerical results.

No. I am saying C++ is not faster.

I really do appreciate the discussion.