In Defense of C++ • Hacker News Board

Re: In Defense of C++

#381

Post by steveklabnik » Wed, Sep 17, 2025, 5:17 PM UTC

jandrese wrote: post #366

duped wrote: post #57

Earlier quoted context omitted.

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

You also don't do "rustc build". Cargo is a build system too. The whole point of pkg-config is to tell the compiler where those packages are. I mean yeah, that's the point of having a tool like that. It's fine that the compiler doesn't know that, because its job is turning source into executables, not being the OS glue. I'm not sure "having a linker" is a weakness? What are talking about? It is true that you need to…

I'm not your parent, but the overall point of this kind of thing is that all of these individual steps are more annoying and error-prone than one command that just takes care of it. `cargo build` is all you need to build the vast majority of Rust projects. No need to edit the Makefile for those headers, or remember which commands you need to install the various dependencies, and name them individually, figuring out which name maps to your distro's naming scheme, etc. It's not just "one command vs five" it's "one command for every project vs five commands that differ slightly per project and per platform". `make` can come close to this, and it's why people love `./configure; make`, and there's no inherent reason why this couldn't paper over some more differences to make it near universal, but that still only gets you Unix platforms.

> but on the other hand you don't end up in a situation where you need virtual environments for every application because they've all downloaded slightly different versions of the same packages.

The real downside here is that if you need two different programs with two different versions of packages, you're stuck. This is often mitigated by things like foo vs foo2, but I have been in a situation where two projects both rely on different versions of foo2, and cannot be unified. The per-project dependency strategy handles this with ease, the global strategy cannot.

Re: In Defense of C++

#382

Post by Jtsummers » Wed, Sep 17, 2025, 5:25 PM UTC

gpderetta wrote: post #341

MontagFTB wrote: post #37

When NIST released its summary judgement against C++ and other languages it deemed memory unsafe, the problem became less technical and more about politics and perception. If you're looking to work within two arms' length of the US Government, you have to consider the "written in C++" label seriously, regardless of how correct the code may be.

At some point the US government required ADA for all new development. Yet here we are.

ADA is still the law, but, yes, Ada the language was mandated for 5 or 6 years and everyone got waivers for it anyways.

A big difference between the Ada mandate and this current push is that the current effort is not to go to one language, but to a different category of languages (specifically, "memory safe" or ones with stronger guarantees of memory safety). That leaves it much more open than the Ada mandate did. This would be much more palatable for contractors compared to the previous mandate.

Re: In Defense of C++

#383

Post by saghm » Wed, Sep 17, 2025, 5:31 PM UTC

lelanthran wrote: post #331

saghm wrote: post #322

Earlier quoted context omitted.

And yet, they both still suffer from the flaw that the parent comment cites. Describing a shared property doesn't imply a claim that they're the same language.

> And yet, they both still suffer from the flaw that the parent comment cites. I dunno; the flaw is not really comparable, is it? The skill and discipline required to write C bug-free is an orders of magnitude less than the skill and discipline required to write C++. Unless you read GGPs post to mean a flaw different to "skill and discipline required".

I'd argue that their point was that the required amount of skill and discipline of either is higher than it's worth at this point for new projects. The difference doesn't matter if even the lower of the two is too high.

Re: In Defense of C++

#384

Post by lelanthran » Wed, Sep 17, 2025, 6:16 PM UTC

butterisgood wrote: post #49

A pet peeve of mine is when people claim C++ is a superset of C. It really isn't. There's a lot of little nuanced differences that can bite you. Ignore the fact that having more keywords in C++ precludes the legality of some C code being C++. (`int class;`) void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit behavior in C++). C…

> void * implicit casting in C just works, but in C++ it must be an explicit cast

In C, casting a `void *` is a code smell, I feel.

Most confusing one is how the meaning of `const` differs between C and C++; I'm pretty certain the C `const` keyword is broken compared to `const` in C++.

Re: In Defense of C++

#385

Post by Defletter » Wed, Sep 17, 2025, 6:27 PM UTC

palata wrote: post #378

Defletter wrote: post #342

Earlier quoted context omitted.

> AUR stands for "Arch User Repository". It's not the official system repository. Okay... and? The point being made was that the issue of package managers remains: do you really think users are auditing all those "lib " dependencies that they're forced to install? Whether they install those dependencies from the official repository or from homebrew, or nix, or AUR, or whatever, is immaterial, the developer washed the…

> But this is why Debian is so revered: they understand this dynamic and so maintain repositories that can be trusted. So you do understand my point about AUR. AUR is like adding a third-party repo to your Debian configuration. So it's not a good example if you want to talk about official repositories. Debian is a good example (it's not the only distribution that has that concept), which proves my point and not yours…

Your defensiveness is completely hindering you and I cannot be bothered with that so here are some much needed clarifications:

> I am not a C/C++ cultist at all, and I actually don't like C++ (the language) so much (I've worked with it for years). I, for one, do not love it when there is an exploit in a language package manager.

If you do neither of those things then did it ever occur to you that this might not be about YOU?

> I find it ironic that when I explain that my problem is that I want to be able to audit (and maintain, if necessary) my dependencies, the answer that comes suggests that I am incompetent and "inexpertly" doing my job.

Yeah, hi, no you didn't explain that. You're probably mistaking me for someone else in some other conversation you had. The only comment of yours prior to mine in the thread is you saying "I can use pkg-config just fine." And again, you're thinking that I'm calling YOU incompetent, or even that I'm calling you incompetent. But okay, I'm sure your code never has bugs, never has memory issues, is never poorly designed or untested, that you can whip out an OpenGL alternative whatever in no time and it be just as stable and battle-tested, and to say otherwise must be calling you incompetent. That makes total sense.

> AUR stands for "Arch User Repository". It's not the official system repository.

> So it's not a good example if you want to talk about official repositories.

I said system package, not official repository. I don't know why you keep insisting on countering an argument I did not make. Yes, system packages can be installed from unofficial repositories. I don't know how I could've made this clearer.

--

Overall, getting bored of this, though the part where you harp on about doing dependencies properly compared to me and not elaborating one bit is very funny. Have a nice day.

Re: In Defense of C++

#386

Post by tialaramex » Wed, Sep 17, 2025, 6:42 PM UTC

fithisux wrote: post #216

charlieflowers wrote: post #118

Earlier quoted context omitted.

> "while C++ continues to dominate ... performance-critical domains" Why performance-critical domains? Does C++ have a performance edge over Rust?

That is what the article says.

But you stated it was "the truth" and so we might reasonably wonder why you think so, unless it's that you just believe anything you read.

"ABI: Now or never" by Titus Winters addresses some perf leaks C++ had years ago, which it can't fix (if it retains its ABI promise). They're not big but they accumulate over time and the whole point of that document was to explain what the price is if (unlike Rust) you refuse to take steps to address it.

Rust has some places where it can't match C++ perf, but unlike that previous set Rust isn't obliged to keep one hand tied behind its back. So this gently tips the scales further towards Rust over time.

Worse, attempts to improve C++ safety often make its performance worse. There is no equivalent activity in Rust, they already have safety. So these can heap more perf woes on a C++ codebase over time.

Re: In Defense of C++

#387

Post by butterisgood » Wed, Sep 17, 2025, 6:58 PM UTC

wvenable wrote: post #77

butterisgood wrote: post #55

Earlier quoted context omitted.

Overloaded operators were a terrible mistake in every programming language I've encountered them in. (Yes, sorry Haskell, you too!) I don't think move semantics are really that bad personally, and some languages move by default (isn't that Rust's whole thing?). What I don't like is the implicit ambiguous nature of "What does this line of code mean out of context" in C++. Good luck! I have hope for C++front/Cpp2. http…

Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an add in your custom numeric data type is good. But using << for output is bad.

I kind of like that OCaml, which I've also not used a great deal, has different operators for adding floats vs integers etc...

Extremely clear at the "call site" what's going on.

Re: In Defense of C++

#388

Post by zenxyzzy » Wed, Sep 17, 2025, 7:00 PM UTC

Don't lump c++ in with c. C++ is a nightmare amalgamation of every bad idea in software development. C is a thing of great beauty with a cheek mole. C++ is a metastatic cancer.

Write disciplined, readable c, use valgrind and similar tools, and reap unequalled performance and maintainability

Re: In Defense of C++

#389

Post by butterisgood » Wed, Sep 17, 2025, 7:00 PM UTC

112233 wrote: post #184

LexiMax wrote: post #98

Earlier quoted context omitted.

I will die on the hill that string concatenation should have its own operator, and overloading + for the operation is a mistake. Languages that get it right: SQL, Lua, ML, Perl, PHP, Visual Basic.

Tangential, but Lua is the most write-only language I have had pleasure working with. The implementation and language design are 12 out of 10, top class. But once you need to read someone else's code, and they use overloads liberally to implement MCP and OODB and stuff, all in one codebase, and you have no idea if "." will index table, launch Voyager, or dump core, because everything is dispatched at runtime, it's pa…

Perl was one for me that I always had a little trouble reading again later.

I guess forth as well... hmmm

Re: In Defense of C++

#390

Post by fluorinerocket » Wed, Sep 17, 2025, 7:02 PM UTC

AnimalMuppet wrote: post #337

zbentley wrote: post #310

Earlier quoted context omitted.

Regrettably, “intended purpose” is highly subjective. Sure, Reasonable minds can and do differ about where the line is in many of those cases. And because of that variability of interpretation, we get extremely hard to understand code. As much as I have seen value in overloading at times, I’m forced to agree that it should probably not exist entirely.

Depends on what you're trying to understand. Let's say I have matrices, and I've overloaded * for multiplying a matrix by a matrix, and a matrix by a vector, and a matrix by a number. And now I write a = b * c; If I'm trying to understand this as one of a series of steps of linear algebra that I'm trying to make sure are right, that is far more comprehensible than a = mat_mult(b,c); because it uses math notation, and…

but is it element by element multiplication, or matrix multiplication? I honestly just prefer calling matmul.