Comment by buserror | Hacker News Reader

Comment by buserror | Hacker News Reader

I love C, I really don't see what the fuss is about about 'replacing' it really. It's a sharp tool, requiring care and attention.

I did C++ for about 20 years, and gradually reverted to C, simply because of the footprint and the ease of maintaining a C codebase compared to a C++ codebase. C++ codebase's footprint will /explode/ very quickly, while it's really, really hard to do that with C.

You can't have 'shockwave' effects in C codebases; you can't have an intern adding a subtle 2 liner to your codebase in an obscure base class and make the footprint of your application explode. (been there...). It's a lot easier to review, test and maintain over a number of years.

Also, I've grown up considerably since I believed object oriented programming is THE way to solve everything related to programming problems, I've seen a lot of cases where you'd have a spaggetti plate of classes to solve a problem while you in fact could have solved that problem in a 15 line static function.

C -- especially C99 with it's extensions -- is nice, lightweight, hard to mess around with. it's actually a sharp tool but at least it's a straight sharp tool. You know where it's going and how it can hurt you. It's not the case for many of the other solutions who just add bloat to try to hide the fact that they are about as sharp cutting, but it'll get you at the back of the head, later :-)

I keep a keen eye on what's going on with Rust and Go in particular, but it'll be a long time still for me to commit to any of the new kids on the block. Right at this minute I imagine myself easily having to rage-recode it in C at some critical point because of some unforeseen effect.

My only regret with C is that the C committee is completely out there. C11 doesn't solve any of the problems that would be useful for 99% of C programming. Like, rolling in some of the GNU extensions that have been around for 25+ years (case X...Y comes to mind!)

> I really don't see what the fuss is about about 'replacing' it really. It's a sharp tool, requiring care and attention.

I really like the take on the "sharp tools" analogy here: https://www.schneems.com/2016/08/16/sharp-tools.html . Your tool might be sharp, but that doesn't mean that you can't make it safer to use.

That thing looks like it could kill a man if dropped from sufficient height. On the other hand, if I envision it without a case, I'm still not seeing a terribly dangerous object.

> This design is an evolution of planes over centuries of use

How did early ones look like then? Was getting hurt by them a problem, at all?

I'm not debating that main point, that in many cases, safety and usefulness are orthogonal. But that example is kind of worse than none.

The C/C++ toolchain has been working to add guards and guides to their sharp tools. Things like the various sanitizers in the llvm toolset have already meant that a lot of bugs that would have been released are instead fixed beforehand. You also have things like OpenBSD's implementation of malloc which also helps in the software feedback loop in finding logic errors that allow for things like use after free errors. C still requires attention, but there are a lot of places where it's harder to cut yourself.

I personally use libtalloc [0] for my allocations in C. Small footprint, excellent feature set, and it has heap checks, reference counting and all the gizmos you'd like in an allocation library. It's actually awesome, I highly recommend it.

For C 'gotcha' cleanups, you can use cppcheck of course (highly recommended) but there's also 'scan-build' the static analyzed from clang.

[0]: https://talloc.samba.org/talloc/doc/html/index.html

Love talloc: just taking the opportunity to plug ccan/tal which I wrote after hacking on talloc for a bit:

http://ccodearchive.net/info/tal.html

Cool, why the parallel project, if I may ask? What did you find you needed 'better' than talloc? :-)

Case in point:

https://www.youtube.com/watch?v=eiYoBbEZwlk

Maybe we need to use your sharp tools point with that video. It drives the point home with even experienced people losing fingers to their tools followed by tech modified to prevent it. The demo also never gets old. Just too badass.

It's correct to say that C is a more explicit programming language than C++, where each line of code won't have large side-effects in performance or code size.

The consequence is having to painstakingly code everything at a low level of detail though, with only macros and its limited functions to rely on for code reuse. This would be fine for low-level embedded work, but anything other than that is simply painful, unproductive and in my opinion not fun at all. I shudder at the thought of having to manually free resources, to use the embarrassing C strings and arrays or having to write dozens or hundreds of line of code to do one simple thing that C++ can do more safely and also in a highly-reusable way.

C is inadequate and has been for a long time. Its status of mythical, hardcore programming language continues to protect it, but slowly people are becoming more outraged at its inadequacies, as they should be. That's what the fuss is about.

Indeed. It's certainly possible to make a language with safety checks that could be turned off in the final version which then has the same performance, but has built in help during development, as well as less cryptic notation. As stated elsewhere, Pascal/Modula (for example) has some very nice features and is written at about the same level.

As for small devices in this day and age, it's not like we can't use cross compilers hosted on desktop computers, since that what phone/tablet systems already do.

> I love C, I really don't see what the fuss is about about 'replacing' it really. It's a sharp tool, requiring care and attention.

You just answered your own question: most people don't apply sufficient care and attention. So should we leave sharp tools lying around and encourage their use knowing they're going to be abused and cause serious problems?

> you can't have an intern adding a subtle 2 liner to your codebase in an obscure base class and make the footprint of your application explode.

What do you mean by "footprint" here? Because if it's heap space or CPU, you can certainly have it.

I don't know, if my large, commercial application suddenly starts taking twice the memory, or takes twice the time it used to take to start, can I 'have it'?

And if I can 'have' that, where do I stop?

That was my principal problem with C++ in the end; you'd get some people in the codebase, and then it was endless fear of someone screwing it up, or deciding that it was such a good idea to add 'boost' thingies to the application because it was SO much nicer. And added 20MB to the installer size (let alone memory footprint).

I remember one day when I investigated why the new version of our commercial application was taking about a minute to startup while it used to take about 15 seconds...

After a long time, pain and effort, it turned out that someone had decided that one of the String class accessors would take it's String parameter as a value, and not as a reference. ONE character source code difference, but it made the millions of Strings created at startup being duplicated, converted back forth from UTF16 to UTF8, destructed etc etc etc.

C++ is a horrible language

It's too late for your project, but in case anyone else has similar issues, some things can help:

* coding standards (e.g: boost X is forbidden). Should be checked by the CI with clang-format + e.g. a Python script.

* code review

* static analysis (e.g: clang-tidy)

* performance-focused integration tests

Oh, now I get your point.

Yes, C++ is much easier to mess with.

Reply on news.ycombinator.com