4 ms·

Anyone who uses the construction "C/C++" doesn't write modern C++, and probably isn't very familiar with the recent revisions despite TFA's claims of writing it

Anyone who uses the construction "C/C++" doesn't write modern C++, and probably isn't very familiar with the recent revisions despite TFA's claims of writing it every day for decades. Far from being just "C with classes", modern C++ is very different than C. The language is huge and complex, for sure, but nobody is forced to use all of it. No HN comment can possibly cover all the use cases of C++ but in general, unless you have a very good reason not to: - eschewing boomer loops in favor of ranges - using RAII with smart pointers - move semantics - using STL containers instead of raw arrays - borrowing using spans and string views These things go a long way towards, shall we say, "safe-ish" code without UB. It is not memory-safe enforced at the language level, like Rust, but the upshot is you never need to deal with the Rust community :^)

rectang 5mo ago
> the upshot is you never need to deal with the Rust community In the end, everything comes down to culture war.
- stackghost 5mo ago
  Perhaps we should rewrite our culture in Rust.
- jim33442 5mo ago
  I've never noticed an issue with this using any of those three languages
veltas 5mo ago
Although some people, like Bjarne Stroustrup, object to the term C/C++, it's a bit like Richard Stallman objecting to the term "Linux". The fact is it can mean "C or C++", and I wouldn't assume the author thinks they're the same, but they're talking about both of them together in the same sentence. This seems reasonable given this is about undefined behavior, and it's trivial to accidentally write UB-inducing code in C++ even with modern style (although I'd say you should catch most trivial cases with e.g. ubsan, and a lot of bad cases would be avoided with e.g. ranges, so I think the article is exaggerating the issue).
- stackghost 5mo ago
  Well, the author explicitly refers to "C/C++" as one language: >After all, C/C++ is not a memory safe language.
  - thomashabets2 5mo ago
    That is a typo, that I think I introduced when I went back to clarify that it applies to C++ too. Will fix it.
flohofwoe 5mo ago
"C/C++" is still a useful term for the common C/C++ subset :) As far as stdlib usage is concerned: that's just your opinion. The stdlib has a lot of footguns and terrible design decisions too, e.g. std::vector pulling in 20k lines of code into each compilation unit is simply bizarre. Also: - eschewing boomer loops in favor of ranges Those "boomer loops" compile infinitely faster than the new ranges stuff (and they are arguably more readable too): https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ - borrowing using spans and string views Those are just as unsafe as raw pointers. It's not really "borrowing" when the referenced data can disappear while the "borrow" is active.
deleted 5mo ago
[deleted]
SpaceNugget 5mo ago
I totally agree that modern c++ is pretty robust if you are both a well seasoned developer and only stick to a very blessed subset of it's features and avoid the historical baggage. However, that's obviously not the point? Ignoring the idea that people can/should just "git gud" and write perfect code in a language with lots of old traps, you can't control how everyone else writes their code, even on your own team once it gets big enough. And there will always be junior devs stumbling into the bear traps of c/c++ (even if the rest of the codebase is all modern c++). So no matter how many great new features get added to C++, until (never) they start taking away the bad ones, the danger inherent to writing in that language doesn't go away. Also, safe != non-UB. TFA isn't so much about memory safety anyway.
m-schuetz 5mo ago
C/C++ is a perfectly fine term for C or C-style C++. The languages can be very close, and personally I prefer C-style C++ miles over some of the half-baked modern nonsense. I mean, I do use C++23 since it has some great additions, but I'm ditching like 90% of the stuff that only adds complexity without much benefit.
thomashabets2 5mo ago
Author here. In the context of UB discussion, the arguments apply equally to C and C++. How would you write that? I entirely agree with all your points that C and C++ are completely different languages at this point. And yet I wanted to write this post about something that is true for both.
jim33442 5mo ago
You can write C++ in a way that's similar to C if you want and run into some of the same UB. Normally I don't like the "C/C++" thing, but in this context it makes sense.

rectang 5mo ago

> the upshot is you never need to deal with the Rust community In the end, everything comes down to culture war.

stackghost 5mo ago
Perhaps we should rewrite our culture in Rust.
jim33442 5mo ago
I've never noticed an issue with this using any of those three languages

veltas 5mo ago

Although some people, like Bjarne Stroustrup, object to the term C/C++, it's a bit like Richard Stallman objecting to the term "Linux". The fact is it can mean "C or C++", and I wouldn't assume the author thinks they're the same, but they're talking about both of them together in the same sentence. This seems reasonable given this is about undefined behavior, and it's trivial to accidentally write UB-inducing code in C++ even with modern style (although I'd say you should catch most trivial cases with e.g. ubsan, and a lot of bad cases would be avoided with e.g. ranges, so I think the article is exaggerating the issue).

stackghost 5mo ago
Well, the author explicitly refers to "C/C++" as one language: >After all, C/C++ is not a memory safe language.
- thomashabets2 5mo ago
  That is a typo, that I think I introduced when I went back to clarify that it applies to C++ too. Will fix it.

flohofwoe 5mo ago

"C/C++" is still a useful term for the common C/C++ subset :) As far as stdlib usage is concerned: that's just your opinion. The stdlib has a lot of footguns and terrible design decisions too, e.g. std::vector pulling in 20k lines of code into each compilation unit is simply bizarre. Also: - eschewing boomer loops in favor of ranges Those "boomer loops" compile infinitely faster than the new ranges stuff (and they are arguably more readable too): https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ - borrowing using spans and string views Those are just as unsafe as raw pointers. It's not really "borrowing" when the referenced data can disappear while the "borrow" is active.

deleted 5mo ago

[deleted]

SpaceNugget 5mo ago

I totally agree that modern c++ is pretty robust if you are both a well seasoned developer and only stick to a very blessed subset of it's features and avoid the historical baggage. However, that's obviously not the point? Ignoring the idea that people can/should just "git gud" and write perfect code in a language with lots of old traps, you can't control how everyone else writes their code, even on your own team once it gets big enough. And there will always be junior devs stumbling into the bear traps of c/c++ (even if the rest of the codebase is all modern c++). So no matter how many great new features get added to C++, until (never) they start taking away the bad ones, the danger inherent to writing in that language doesn't go away. Also, safe != non-UB. TFA isn't so much about memory safety anyway.

m-schuetz 5mo ago

C/C++ is a perfectly fine term for C or C-style C++. The languages can be very close, and personally I prefer C-style C++ miles over some of the half-baked modern nonsense. I mean, I do use C++23 since it has some great additions, but I'm ditching like 90% of the stuff that only adds complexity without much benefit.

thomashabets2 5mo ago

Author here. In the context of UB discussion, the arguments apply equally to C and C++. How would you write that? I entirely agree with all your points that C and C++ are completely different languages at this point. And yet I wanted to write this post about something that is true for both.

jim33442 5mo ago

You can write C++ in a way that's similar to C if you want and run into some of the same UB. Normally I don't like the "C/C++" thing, but in this context it makes sense.