Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

161–170 of 470 posts

Re: In Defense of C++

#161

Post by asa400 »

nothrabannosir wrote: post #147
duped wrote: post #103

Earlier quoted context omitted.

Every modern language seems to have an answer to this problem that C and C++ refuse to touch because it's out of scope for their respective committees and standards orgs

On the front page right now: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised (stepsecurity.io) 935 points by jamesberthoty 16 hours ago | flag | hide | 730 comments Maybe obstreperous dependency management ends up being the winning play in 2025 :)

Just think of how many _more_ vulns C and C++ could be responsible for if they had package modern managers! :)

Re: In Defense of C++

#162

Post by fluoridation »

BeetleB wrote: post #52

> Here’s a rule of thumb I like to follow for C++: make it look as much like C as you possibly can, and avoid using too many advanced features of the language unless you really need to. Also, avoid using C++ classes while you're at it. I recently had to go back to writing C++ professionally after a many-year hiatus. We code in C++23, and I got a book to refresh me on the basics as well as all the new features. And ma…

std::optional does have dereference checking, but it's a run-time check: std::optional::value(). Of course, you'll get an exception if the optional is empty, because there's nothing else for the callee to do.

Re: In Defense of C++

#163

Post by TinkersW »

StillBored wrote: post #63
sunshowers wrote: post #22

Earlier quoted context omitted.

Exactly! This is my problem with the C++ community's culture. At no point is safety put first.

Its worse. The day I discovered that std::array is explicitly not range/bounds checked by default I really wanted to write some angry letters to the committee members. Why go through all the trouble to make a better array, and require the user to call a special .at() function to get range checking rather than the other way around? I promptly went into my standard library and reversed that decision because if i'm goin…

std::array [] is checked if you have the appropriate build settings toggled, which of course you should during development.

The same applies to many of the other baseless complaints I'm seeing here, learn to use your tools fools.

Re: In Defense of C++

#164

Post by vlovich123 »

AdieuToLogic wrote: post #152
vlovich123 wrote: post #145

Earlier quoted context omitted.

You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system where everyone does the bare minimum to meet the near term task only and it devolves into a mess no one wants to touch over enough time. Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fi…

> You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system ... The scenario you are describing does not make sense for the commonly accepted industry definition of "build system." It would make sense if, instead, the description was "application", "product", or "system." Many software engineers use and interpret the p…

I can only relate to you what I’ve observed. Engineers were hired to rewrite the Make-based system into Bazel and maintain it for single executable distributed to the edge. I’ve also observed this for embedded applications and other stuff.

I’m not sure why you’re dismissing it as something else without knowing any of the details or presuming I don’t know what I’m talking about.

Re: In Defense of C++

#165

Post by fluoridation »

Night_Thastus wrote: post #115
thelittlenag wrote: post #101

Earlier quoted context omitted.

I'm old enough to recall when boost first came out, and when it matured into a very nice library. What's happened in the last 15 years that boost is no longer something I would want to reach for?

C++11 through 17 negated a lot of its usefulness - the standard library does a lot of what Boost originally offered. Alternative libraries like QT are more coherent and better thought out.

Qt is... fine... as long as you're willing to commit and use only Qt instead of the standard library. It's from before the STL came out, so the two don't mesh together really at all.

Re: In Defense of C++

#166

Post by asa400 »

pclmulqdq wrote: post #148
jimbob45 wrote: post #144

Earlier quoted context omitted.

You say that as if Cargo, MSBuild, and pip aren’t massively loved by their communities.

"Massively loved" and "good decision" are orthogonal axes. See the current npm drama. People love wantonly importing dependencies the way they love drinking. Both feel great but neither is good for you.

Not that npm-style package management is the best we can do or anything, but I would be more sympathetic to this argument if C or C++ had a clearly better security story than JS, Python, etc. (pick your poison), but they're also disasters in this area.

What happens in practice is people end up writing their own insecure code instead of using someone else's insecure code. Of course, we can debate the tradeoffs of one or the other!

Re: In Defense of C++

#167

Post by ergonaught »

It's a fine post except for this:

> Countless companies have cited how they improved their security or the amount of reported bugs or memory leaks by simply rewriting their C++ codebases in Rust. Now is that because of Rust? I’d argue in some small part, yes.

Just delete this. Even an hour's familiarity with Rust will give you a visceral understanding that "Rewrites of C++ codebases to Rust always yield more memory-safe results than before" is absolutely not because "any rewrite of an existing codebase is going to yield better results". If you don't have that, skip it, because it weakens the whole piece.

Re: In Defense of C++

#168

Post by monkeyelite »

ryao wrote: post #110
monkeyelite wrote: post #97

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder but I do

I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C. Problem 1: You might fail to initialize an object in memory correctly. Solution 1: Constructors. Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call. Solution 2: Placement new Problem 3: Now the ty…

I absolutely agree - your chain of reasoning follows as well. It doesn't seem like it at first, but the often praised constructor/destructor is actually a source of incredible complexity, probably more than virtual.

Re: In Defense of C++

#169

Post by monkeyelite »

jandrewrogers wrote: post #139
monkeyelite wrote: post #97

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder but I do

You need something like std::launder in any systems language for certain situations, it isn’t a C++ artifact. Before C++ added it we relied on undefined behavior that the compilers agreed to interpret in the necessary way if and only if you made the right incantations. I’ve seen bugs in the wild because developers got the incantations wrong. std::launder makes it explicit. For the broader audience because I see a lot…

Do you see all the concepts you had to describe here?

> Unless you are a low-level systems developer it is unlikely to affect you.

Making new data structure is common. Serializing classes into buffers is common.

Re: In Defense of C++

#170

Post by moefh »

okanat wrote: post #99
nzeid wrote: post #11

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues. You know, not sure I even agree with the memory leaks part. If you define a memory leak very narrowly as forgetting to free a pointer, this is correct. But in my experience working with many languages including C/C++, forgotten pointers are almost never the problem. You're gonna be…

Nice thing about Rust is not that you cannot write such code, it is you know exactly where you used peaky memory or re-interpreted something as a unsigned integer or replaced your program stack with something else. All of such cases require unsafe blocks in Rust. It is a screaming indicator "here be dragons". It is the do not press this red button unless you intend to. In C and C++ no such thing exists. It is walking…

> All of such cases require unsafe blocks in Rust.

It's true that Rust makes it much harder to leak memory compared to C and even C++, especially when writing idiomatic Rust -- if nothing else, simply because Rust forces the programmer to think more deeply about memory ownership.

But it's simply not the case that leaking memory in Rust requires unsafe blocks. There's a section in the Rust book explaining this in detail[1] ("memory leaks are memory safe in Rust").

[1] https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Post reply on HN