In Defense of C++ • Hacker News Board

Re: In Defense of C++

#371

Post by wvenable » Wed, Sep 17, 2025, 4:39 PM UTC

zbentley wrote: post #310

wvenable wrote: post #77

Earlier quoted context omitted.

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.

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.

> we get extremely hard to understand code

The thing is code without operator overloading is also hard to understand because you might have this math thing (BigIntegers, Matrices) and you can't use standard notation.

Re: In Defense of C++

#372

Post by einpoklum » Wed, Sep 17, 2025, 4:40 PM UTC

imtringued wrote: post #230

jlarocco wrote: post #136

Earlier quoted context omitted.

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.

> I used to write a lot of C++ in 2017... It's bespoke Makefile nonsense

1. Makefiles are for build systems; they are not C++. 2. Even for building C++ - in 2017, there was no need to write bespoke Makefiles, or any Makefiles. You could, and should, have written CMake; and your CMake files would be usable and relevant today.

> Meanwhile my gradle setups have been almost unchanged since that time

... but, typically, with far narrower applicability.

Re: In Defense of C++

#373

Post by rramadass » Wed, Sep 17, 2025, 4:43 PM UTC

estimator7292 wrote: post #316

lelanthran wrote: post #313

Earlier quoted context omitted.

> C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. You can't sensibly talk about C and C++ as a single language. One is the most simple language there is, most of the rules to which can be held in the head of a single person while reading code. The other is one of the most complex programming languages to ever have existed, in which even world-renowned experts in lose their f…

Have you written significant amounts of C or C++? Most people don't write C, nor use the C compiler, even when writing C. You use C++ and the C++ compiler. For (nearly) all intents and purposes, C++ has subsumed and replaced C. Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features. It's still C++ on the C++ compiler. Actual uses of actual C are pretty esoter…

Right on the money!

Other then hardcore embedded guys and/or folks dealing with legacy C code, I and most folks i know almost always use C++ in various forms i.e. "C++ as a better C", "Object-Oriented C++ with no template shenanigans", "Generic programming in C++ with templates and no OO", "Template metaprogramming magic", "use any subset of C++ from C++98 to C++23" etc. And of course you can mix-and-match all of the above as needed.

C++'s multi-paradigm support is so versatile that i don't know why folks on HN keep moaning about its complexity; it is the price you pay for the power you get. It is the only language that i can program in for itty-bitty MCUs all the way to large complicated distributed systems on multiple servers plus i can span all of applications to systems to bare-metal programming.

Re: In Defense of C++

#374

Post by jstimpfle » Wed, Sep 17, 2025, 4:52 PM UTC

AlienRobot wrote: post #308

Defletter wrote: post #233

Earlier quoted context omitted.

This is pure Stockholm syndrome. If I were forced to choose between creating a cross-platform C++ project from scratch or taking an honest to god arrow to the knee, the arrow would be less painful.

I don't want any arrows in my knees but I agree. The main reason I don't want to use C/C++ are the header files. You have to write everything in a header file and then in an implementation file. Every time you want to change a function you need to do this at least twice. And you don't even get fast compilation speed compared to some languages because your headers will #include some library that is immense and then ev…

It gets better with experience. You can have a minimal base layer of common but rarely changing functionality. You can reduce static inline functions in headers. You reduce data structure definitions, but put only forward declarations in header files. (Don't use C++ methods, at least don't put them in an API, because they force you to expose your implementation details needlessly). You can separate data structures from functions in different header files. Grouping functions together with types is often a bad idea since most useful functionality combines data from two or more "unrelated" types -- so you'd rather make function headers "by topic" than putting them alongside types.

I just created a subsystem for a performance intensive application -- a caching layer for millions or even billions of objects. The implementation encompasses over a 1000 LOC, but the header only includes . There are about 5 forward struct declarations and maybe a dozen function calls in that API.

To a degree it might be stockholm syndrome, but I feel like having had to work around a lot of C's shortcomings I actually learned quite a lot that helps me in architecting bigger systems now. Turns out a lot of the flexibility and ease that you get from more modern languages mostly allows you to code more sloppily, but being sloppy only works for smaller systems.

Re: In Defense of C++

#375

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

lelanthran wrote: post #361

steveklabnik wrote: post #349

Earlier quoted context omitted.

Standard C doesn't have inline assembly, even though many compilers provide it as an extension. Other languages do. > After all if everything else is "Just as close as C, but not closer", then just what kind of spectrum are you measuring on The claim about C being "close to the machine" means different things to different people. Some people literally believe that C maps directly to the machine, when it does not. Thi…

> Some people literally believe that C maps directly to the machine, when it does not. Maybe they did, 5 years (or more) ago when that essay came out. it was wrong even then, but repeating it is even more wrong. > This is just a factual inaccuracy. No. It's what we call A Strawman Argument , because no one in this thread claimed that C was uniquely close to the hardware. Jumping in to destroy the argument when no one…

Claiming that a processor is a "C VM" implies that it's specifically about C.

Re: In Defense of C++

#376

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

einpoklum wrote: post #367

jlarocco wrote: post #136

Earlier quoted context omitted.

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it. On Windows and OSX it's even easier - if you're okay writing only for those platforms. It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated…

It is a big deal even after you know how it works. The thing is, the languages like Rust only make this easier within their controlled "garden". But for C and C++, you build in the "world outside the garden" to begin with, where you are not guaranteed of everyone having prepared everything for you. So, it's harder, and you may need third-party tools or putting in some elbow grease, or both. The upside is that when ru…

What is "outside the garden" for Rust?

Re: In Defense of C++

#377

Post by charlieflowers » Wed, Sep 17, 2025, 4:57 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.

It seems you agree? I'd love to hear your thoughts on it. I had gotten the impression (second-hand) that they were roughly equally matched in this regard.

Re: In Defense of C++

#378

Post by palata » Wed, Sep 17, 2025, 4:59 PM UTC

Defletter wrote: post #342

palata wrote: post #275

Earlier quoted context omitted.

> Or do they use system packages like that's any better cough AUR exploits cought . AUR stands for "Arch User Repository". It's not the official system repository. > I'm getting the impression that C/C++ cultists love it whenever there's an npm exploit 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 expl…

> 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: this is better than unchecked repositories in terms of security.

> Whereas the solution C/C++ cultists seem to implicitly prefer is having no repositories because dependencies are, at best, a slippery slope.

Nobody says that ever. Either you make up your cult just to win an argument, or you don't understand what C/C++ people say. The whole goddamn point is to have a trusted system repository, and if you need to pull something that is not there, then you do it properly.

Which is better than pulling random stuff from random repositories, again.

> I actually prefer the dependencies-as-git-submodules approach

Oh right. So you do it wrong, it's good to know and it will answer your next complaint:

> Don't you just love it when one or more of your dependencies has a completely different build system to the others

I don't give a damn because I handle dependencies properly (not as git submodules). I don't have a single project where the dependencies all use the same build system. It's just not a problem at all, because I do it properly. What do I do then? Well exactly the same as what your system package manager does.

> this shouldn't be a problem.

I agree with you. Call it a footgun if you wish, you are the one pulling the trigger. It isn't a problem for me.

> why are any and all comments begging for a first-party package manager immediately swamped with strawmans about npm

Where did I do that?

> It's because of the cultism, and every npm exploit further entrenches it.

It's because npm is a good example of what happens when it goes out of control. Pip has the same problem, and Rust as well. But npm seems to be the worse, I guess because it's used by more people?

Re: In Defense of C++

#379

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

throwawaymaths wrote: post #335

pornel wrote: post #264

Earlier quoted context omitted.

People innately admire difficult skills, regardless of their usefulness. Acrobatic skateboarding is impressive, even when it would be faster and safer to go in a straight line or use a different mode of transport. To me skill and effort is misplaced and wasted when it's spent on manually checking invariants that a compiler could check better automatically, or implementing clever workarounds for language warts that no…

To me a compiler's effort is misplaced and wasted when it's spent on checking invariants that could be checked by a linter or a sidecar analysis module.

Checking of whole-program invariants can be accurate and done basically for free if the language has suitable semantics.

For example, if a language has non-nullable types, then you get this information locally for free everywhere, even from 3rd party code. When the language doesn't track it, then you need a linter that can do symbolic execution, construct call graphs, data flows, find every possible assignment, and still end up with a lot of unknowns and waste your time on false positives and false negatives.

Linters can't fix language semantics that create dead-ends for static analysis. It's not a matter of trying harder to make a better linter. If a language doesn't have clear-enough aliasing, immutability, ownership, thread-safety, etc. then a lot of analysis falls apart. Recovering required information from arbitrary code may be literally impossible (Rice's theorem), and getting even approximate results quickly ends up requiring whole-program analysis and prohibitively expensive algorithms.

And it's not even an either-or choice. You can have robust checks for fundamental invariants built into the language/compiler, and still use additional linters for detecting less clear-cut issues.

Re: In Defense of C++

#380

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

account42 wrote: post #257

summerlight wrote: post #174

Earlier quoted context omitted.

When people are obsessed with over-abstraction and over-generalization, you can often see FizzBuzz Enterprise in action where a single switch statement is more than enough.

I see that more with inheritance including pure virtual interface for things that only have one implementation and actor patterns that make the execution flow unnecessarily hard to follow. Basically, Java written in C++. Most templates are much easier to read in comparison.

Agreed that template itself is not the problem but people are. It is still arguable that template is much more of fun to write clever codes because of its meta programming capability as well as its runtime performance advantages.

With a pure virtual interface you can at least track down the execution path as long as you can spot down where the object is created, but with template black magics? Good luck. Static dispatch with all those type traits and SFINAE practically makes it impossible to know before running it. Concept was supposed to solve this but this won't automatically solve all those problems lurking in legacy codes.