Hacker News Reader

Comment by cageface | Hacker News Reader

Pure C seems to be enjoying a bit of language fad hipness lately but I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C.

That C is still in wide use after 40 years is a testament to the elegance of its original design but let's not get carried away.

View on HN

The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used.

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.

"Subversion"

And don't forget Git! ;)

...because the environment precludes changing? Back when I was pressed into Linux work (years) C++ keywords were used as variable names in standard headers. Made it pretty obvious nobody had ever, ever tried to use C++ for Linux code.

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

> The Linux kernel, Subversion and PHP are pure C. And don't get me started on the BSDs or binutils... ld and libbfd are pure C and its C++ replacement (gold) is still not widely used.

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

But then, the new star (clang/LLVM) is written in C++.

>I don't know anybody that has to maintain a large body of non-trivial, low-level code that chooses pure C over C++. There's a good reason that everything from Solaris to V8 to Photoshop to Quake is written in C++ and not C.

How about the Linux kernel?

And all the BSDs.

I've consulted in the past on embedded projects. In my experience, maintaining a non-trivial body of C++ code is easily a factor of 2-10x harder than maintaining equivalent C code.

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.

Then why doesn't somebody clue in Adobe, Ableton, Epic Games, Pixar, Valve, Google etc and get them to abandon their wicked C++-loving ways? If what you say is true in general then you could save a lot of the brightest engineers in the world a lot of headache.

The reason why games are written in C++ is because the gaming industry was sold on the idea in the mid 90's and now all the tools are written in it.

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"

Also, win32 is a C++ project. There are significant advantages to writing in the same language as the underlying platform.

Solaris is written in C. Same is true for all BSDs, PostgreSQL, nginx and a lot of other high-quality software.

Quake was not written in C++. All of id's games until Doom 3(2004) were written in C.

I think, wolf 3d is C++ too.

Why would you think that? That was their first FPS released way back in 1992.

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.

I'm sorry, you are right, it was indeed in C.

http://www.tarsnap.com/kivaloo.html

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.

All RAD's products are pure C at the interface level. Most of them are pure C at the implementation level, too. The one exception is that Telemetry (which I work on) uses C++ to implement the C interface, but only minimalistically.

I've had the pleasure of integrating your Granny SDK into our engine at the indie iOS shop I work at and it's been a total pleasure to work with and a perfect example of solid C interface design.

Now when can we get telemetry support? ;)

You're in luck! I ported all of Telemetry to OS X (including the visualizer) a few weeks ago, and next week I'm planning on porting the run-time to iOS. With those two big pieces finished, that should give iOS developers a full solution. There's going to be a pure bugfix/stability release early next week, and the release after that should have the iOS goodness.

Hi, I'd like to chime in as an embedded sw dev. We're still there, designing your equipment, coding quietly and happily in C... :)

Something about most C++ code I've read makes me a little sad. It's a great language, but many features seem to be abused.

Quake, Quake II and Quake III are C.

Some good counter-examples but these are outliers. You can't seriously argue that the vast majority of big, high-performance apps aren't written in C++ and for good reason. Cubase, Photoshop, Maya, Renderman, Chrome, Java/JVM, virtually all A-list video games etc.

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

You subverted your argument by including the term 'low-level'. Of course, that's all written freshly in C to this day.

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.

Reply on news.ycombinator.com