Ugh, old, old FUD from years back (not you, the article). g++ (the only C++ compiler that's relevant) has been as fast as gcc for years (they use the same back-end).

After this was released: http://developers.slashdot.org/article.pl?sid=04/10/27/21102... (the original link is lost, but I'll summarize below), and the community ignored it, I stopped really respecting the technical merits of the Linux community. It's a hacker's hobby that became good enough in a group of systems that stagnated (see http://doc.cat-v.org/bell_labs/utah2000/ ).

<rant ignore="recommended"> Frankly the quick reason is that the kernel is a hobby for many, and a fetish for some. Engineering decisions are made at the geek level, not a management level, e.g., "This cool hack will make it faster for the $250k big-iron box I got on eBay" vs "We should put together a unified infrastructure for making 802.11 easy to use." </rant>

<sidebar title="Linux on C++ Patch"> The work I mentioned above (to the side?) was an effort to make the kernel compile on g++. They also made exception handling faster than printk(). Like it or not, a lot of techniques used in a "modern" unix kernel are language features in C++, e.g., vnodes/vtables. On top of that, exceptions provide a much more structured way to describe (via an entire type system, not just error codes!) and handle (catch what's relevant to you, pass on what's not) errors, with the ability to automatically clean up resources and state along the way (local variable destructors, the 'operate-and-swap' idiom for stl containers).

But no, all we have is ~15 yr old FUD quoted over and over, ironically similar to the windows users they love to complain about. </sidebar>

> Ugh, old, old FUD from years back (not you, the article). g++ (the only C++ compiler that's relevant) has been as fast as gcc for years (they use the same back-end).

g++'s generated code is not as fast as gcc's, despite their common infrastructure. For the last month or two, gcc has been compilable with g++ as well (it has been rewritten in the common C/C++ subset), and the reports are of about a 10% decrease in speed when compiling with g++.

Odd, CPU-wise it does pretty well here: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

(g++ vs gcc in the language shootout).

I'm gonna guess gcc's been optimized for compilation by gcc (or at least the bootstrap version), and that no such optimization's been done for g++.

Don't believe one benchmark.

In reality any C++ code can (and it's internally) translated to C one (that's called the front-end compiler). The back-end is the same.

The only difference is when there are things required by the C++ runtime (mainly exceptions and RTTI, and in some sense virtual functions).

I'm sure that if you take a "C" code, and compile it under "C++" compiler (given that it can compile) - you won't see difference.

Please disassemble it, and see for yourself.

That's the other problem with C++ - no one actually for real writes in full C++ - you always end up sacrificing features (exceptions most notably) to have running on embedded systems, or game consoles. And no RTTI there too.

For example if you have exceptions enabled, there must be some infrastructure for handling them. Certain C++ compilers generate almost no code for handling exceptions, but the handling is expensive. Other compensate that with more generated code (for keeping stack frames), and faster handling.

So you can say - well - disable the exceptions.... But is that C++ anymore?

For example Common Lisp is multi-paradigm, but there is no Common Lisp without CLOS. It can't be disabled, and still call itself Common Lisp.

Same with RTTI in C++ - it's in the language, but again it can be disabled. Or new/delete (and the missing reallocate construct).

So C++ the language, and C++ the runtime being used are quite different things when comes to usage.