Hacker News Reader

Comment by fhood | Hacker News Reader

Oddly enough C never bothered me. It has its purpose, and despite its flaws it still feels elegant. C++ however should be illegal. When do we get to say goodbye to it?

Edit/Continuation: I feel like the freedom offered by C works because of it's simplicity, and as a language for embedded systems I still enjoy developing in C. As someone who recently started working primarily in C++ though I am frequently astounded by the choices that were made. And to make things worse, offering C style controllability in a complex OO language doesn't work well. I shouldn't have to feel like I need to read the designers minds to predict how a language will act.

View on HN

After programming in C++ for nearly a decade, I too came to the same conclusion. I was always told to avoid C (because dangling pointers and what not) but now even though C++ has some things I like, overall I think C is a lot easier to 'think' in. Even though dangling pointers etc are an issue, you'll pick up good habits over time and avoid many usual C issues.

I think what replaces C should be something like Nim, which compiles to C and also has great C interop. C++ is definitely not it.

Nim is def. a nice option

So is Dlang to anyone who likes Algol style languages, with the added benefit that you can seamlessly use C/C++ code or libraries.

>dangling pointers

C has no standard language provided range checks, and pointer security, but the amount of compiler macroses that do the same/coverage tools/runtime security tools/checks provided by compilers is huge.

At least part of "inherent issues" of C that Rust advocates often cite was long solved by these tools long time ago.

They are not a bullet proof solutions to lack of security features in C, but neither are the built in checks of novel languages. The amount of NX breakouts, syscall hijackings, clever tricks around range checks in so called secure languages being demonstrated every year confirms that.

>dangling pointers etc are an issue

In the safety critical programming we use subset of C or (C++) with static code analysis. It's possible to prove that there is no dangling pointers, divisions by zero, floating point exceptions (with assertions), out of bounds array access. It's called verification.

Programming is limited into MISRA C and then it's run trough static code analysis tool like Astree to prove that there is no runtime errors. There are still bugs, but they are not "typical C errors". Waiting for new systems programming candidates to get their toolchain to match the task.

https://www.absint.com/astree/index.htm

> Waiting for new systems programming candidates to get their toolchain to match the task.

Ada, doing it since 1983.

> Even though dangling pointers etc are an issue, you'll pick up good habits over time and avoid many usual C issues.

The security track records of nearly all large scale network facing C projects disagree with you.

Why do you call it "thinking in C" as opposed to structural code? So you like thinking in terms of ststically sized arrays? C++ has proper arrays since C++11. Nobody can help you if you like malloc, but using shared_ptr and unique_ptr gets close enough.

Nothing prevents quitting structural code in C++. Or even functional for that matter. (Though function objects are not quite light yet.)

There are even safe subsets where at most you will get an exception when you try to do something dirty. Easy to enforce.

Certain things like compile time calculation (being enhanced by the moment) do not even reasonably exist in C or for that matter Nim.

The about one gripe with C++ is ABI or rather lack thereof. Three other is the amount of legacy code written in C or outdated dialects of C++.

I'm curious about what's fueling your hatred of C++. In my experience it depends heavily on how it's being used. Modern C++ used competently can get you really far, but I don't know how easy it is to find an environment like that these days, considering the amount of garbage code you can find written in it.

Pretty sure you just answered your own question.

To be fair, the garbage code part definitely also goes for C. The issue seems to be largely orthogonal to language preferences and capabilities.

Reply on news.ycombinator.com