Hacker News Reader

Comment by pjmlp | Hacker News Reader

I wish, althought C++ was born on the same building as C (kind of) and has enjoyed first class support on UNIX, it has hardly taken its place at the kernel level or syscalls.

So most UNIX/POSIX projects, even new ones, will default to C.

Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors, debugging tools, available libraries.

Arduino and mbed are the exceptions, not the rule.

Even Microsoft despite all their security talk around Azure Sphere, just releases a pure C SDK for it.

Which is while I tend to rant about C, I also argue that tooling improvements related to security are more than welcomed, and knowledge about best practices when coding in C should be more widespread.

It is the COBOL of systems programming languages (about 10 years younger) and it isn't going away for the foreseable future.

View on HN

> Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors

And why do you think this is so?

When I was starting with embedded development I missed C++ as I felt compelled to reinvent same things that were given in C++.

But then I grew up to learn there is a hefty price to pay for it and in embedded development those problems are blown due to properties of the environment and types of projects you build.

It is one thing for a game to be constantly crashing and it is another if this is happening to an embedded device.

When you develop embedded code it is way more important to understand exact consequences of your actions and C++ is trying to hide those from you as much as possible.

There are also other requirements like being able to easily ascertain the amount of stack used, ability to use exclusively statically allocated memory, etc. that are conflicting with C++ or at least making it difficult to enforce them in C++.

I am very happy to see Rust is overtaking C++ in embedded and is an answer to C problems without creating (too many) of its own.

It is a culture problem, something that only will change with mentality reboot.

"CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”"

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

"Writing better embedded Software - Dan Saks - Keynote Meeting Embedded 2018"

https://www.youtube.com/watch?v=3VtGCPIoBfs

"Embedded & C++ - Meeting 2017 Keynote"

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

In a way, the same kind of subculture in C++ that jumps in cries of horror if you happen to use std::vector/array/string with bounds checking enabled.

I think the basic issue is that C++ want to spend a lot of time focusing on C++ The Language, while C developers mostly want to focus on developing the logic of whatever they are doing.

When I worked on C++ projects half of the discussion was on just the use of language or various consequences of it.

On C projects that never happens. There is nothing to talk about so everybody focuses on making the project better.

Things I don't miss after I switched from C++ to C:

-- discussing compiler feature set,

-- discussing how exactly to format complex C++ constructs,

-- regular calls for help from less experienced devs to more experienced C++ "gurus" for their wisdom to just interpret what the code does or tell them how to write the thing they want to write,

-- trainings for less experienced developers so that they can even understand the syntax of the code,

-- hunting bugs due to lack of understanding of complex internal mechanisms,

-- having hard time working with a debugger on complex code,

-- not being able to tell wtf is the exact type of the thing that I am looking at or what exact code is going to get execute when I use an operator or call a function. The IDE not being able to locate it for me is an added "bonus".

What I miss most when working in C instead of C++ is that although lint was created in 1979, most projects still avoid any kind of static analysis.

Then there are the discussions on:

- what warnings to turn on as errors

- what ISO C says and what compiler XYZ does, with many not even aware to the differences

- not clear understanding of the 200+ UB cases documented on the standard

- in-house libraries for safer handling of strings and arrays

- experienced developers creating CVEs because they think they are free of such errors (pun intended)

Almost all above applies to C++ too.

It does indeed, with the big difference that C++ community cares to reduce the amount of UB on the standard, and pushes for language features that improve safety.

Now if people choose to ignore the tools available to them, just like they enjoy ignoring lint since 1979, well there is little the doctor can do to save patients that refuse help.

> I think the basic issue is that C++ want to spend a lot of time focusing on C++ The Language, while C developers mostly want to focus on developing the logic of whatever they are doing.

This is just libel, really. There are meta-nerds in C and C++, but there is also a great majority of programmers just interested in delivering good software.

This is a hope OT reply, but I just want you to know that I truly appreciate your commenting on HN. I find myself actively seeking out your comments when browsing. While I may disagree with some of your thoughts (violently in a few cases) I always find them well written and argued. I even find myself wondering what you would think of my pet language project. So, in sum, even if coming to HN is just a fun diversion for you, it actually makes a difference to some people, so thanks.

> Then there is the embedded space where almost 40 years later trying to use C++ instead of C is still an uphill battle, between embedded development communities, tool vendors, debugging tools, available libraries.

I worked in embedded development for over 10 years and at every place it was the norm to use C++ instead of C internally. But when creating libraries for customers to use, these where almost always in C or at least with C bindings.

I guess the reason is that one can use C libraries in C++, but not the other way around.

Reply on news.ycombinator.com