And this came without thinking about it... surely in two more minutes or by going to ohloh I could fire a couple more large bodies of non-trivial low-level C code at you.

And don't forget Git! ;)

I tried writing Linux kernel drivers; it was a horrifying mess. Tragically, it would have been easily managed in C++.

Please pick gcc to mention or, indeed, any other C program ever written, before libbfd ;)

How about the Linux kernel?

I have lots of reasons why this is true, many of which are specific criticisms about C++. There is one issue that is industry specific: Everyone working in embedded has either come from the bottom up (deep firmware in assembly or machine code) or the top down (Java in school), and when you get a dozen people where half of them treat C++ like "C with classes" and the other half treats C++ like it's Java, it's a guaranteed disaster.

For low level systems work, C++ can be considerably more difficult than C to organize and port large programs.

It isn't "C++ is always worse than C" it is "C is often better than C++ for a given task, depending on task"

If you are thinking of Return to Castle Wolfstein, that was C as well, using the Quake 3 engine. But id didn't even make that game.

The author is pretty active here on HN. Very well documented design and goals. Also well documented for what problems it does not solve.

I think around 20k LOC. Seems pretty non-trivial.

Now when can we get telemetry support? ;)

People have codebases that are millions of lines of code in C++ that I don't think would even be possible in pure C.

Assuming that you meant only 'non-trivial': aside from the embedded space, C and GCC still represent the first-tapped resource in many companies. C is terse, well-known, fast and predictable.

I'd go marginally further and claim that, done correctly, gmake and a proper directory hierarchy remain the most effective way of organizing and maintaining a large software project.