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

321–330 of 470 posts

Re: In Defense of C++

#321

Post by selfmodruntime »

chombier wrote: post #272

I've been programming in c++ for 25 years (15 professionally) and I really don't see any reason to keep using it apart from dealing with legacy codebases. Most arguments in the article boil down to "c++ has the reputation of X, which is partly true, but you can avoid problems with discipline". Amusingly, this also applies to assembly. This is _exactly_ why I don't want to code in c++ anymore: I don't want the constan…

Exactly. I’ve been using „Stupid Rust“ for years now where I just liberally clone if I can’t have my way. It‘s not bitten me yet and once the code compiles, it works.

Re: In Defense of C++

#322

Post by saghm »

lelanthran wrote: post #313
jillesvangurp wrote: post #220

C++ and C rely, heavily, on skill and discipline instead of automated checks to stay safe. Over time, and in larger groups of people that always fails. People just aren't that disciplined and they get overconfident of their own skills (or level of discipline). Decades of endless memory leaks, buffer overflows, etc. and the related security issues, crash bugs, data corruption, etc. shows that no code base is really im…

> 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…

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.

Re: In Defense of C++

#323

Post by saghm »

account42 wrote: post #245
jjaksic wrote: post #154

Earlier quoted context omitted.

Wow, I don't understand what anything means in those memes. And I'm so glad I don't! It seems to me that the people/committees who built C++ just spent decades inventing new and creative ways for developers to shoot themselves in the foot. Like, why does the language need to offer a hundred different ways to accomplish each trivial task (and 98 of them are bad)?

Ignorance is not something you should be proud of.

Being wise enough to know what's worth spending time to learn is, though. Knowledge isn't free.

Re: In Defense of C++

#324

Post by account42 »

CalChris wrote: post #111
lang4d wrote: post #19

Earlier quoted context omitted.

My go to for formatting would be clang-format, and for testing gtest. For more extensive formatting (that involves the compiler) clang-tidy goes a long way

I think you meant for more extensive static analysis . Clang-tidy is really awesome. There is also Facebook's Infer . https://fbinfer.com

Clang tidy does both: it can run clang's analyzer [0] (also available with clang++ --analyze or the scan-build wrapper script which provides nicer HTML-based output for complex problems found), has it's own lightweight code analysis checks but also has checks that are more about formatting and ensuring idiomatic code than it is about typical static analysis.

MVSC [1] and GCC [2] also have built-in static analyzers available via cl /analyze or g++ -fanalyzer these days.

There is also cppcheck [3], include-what-you-use [4] and a whole bunch more.

If you can, run all of them on your code.

[0] https://clang-analyzer.llvm.org/

[1] https://learn.microsoft.com/en-us/cpp/build/reference/analyz...

[2] https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.h...

[3] https://cppcheck.sourceforge.io/

[4] https://github.com/include-what-you-use/include-what-you-use

Re: In Defense of C++

#325

Post by duped »

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 :)

Completely unrelated.

Re: In Defense of C++

#326

Post by duped »

jlarocco wrote: post #136
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…

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…

So I come from the C/C++ world, that's part of why I disagree with these takes. I wouldn't say any process involving CMake is "not that big of a deal" because I routinely see veteran developers struggle to edit cmake files to get their code to compile and link.

Re: In Defense of C++

#327

Post by lelanthran »

raverbashing wrote: post #320
lelanthran wrote: post #312

Earlier quoted context omitted.

> This idea is some 10yrs behind. Akshually[1] ... > And no, thinking that C is "closer to the processor" today is incorrect THIS thinking is about 5 years out of date. Sure, this thinking you exhibit gained prominence and got endlessly repeated by every critic of C who once spent a summer doing a C project in undergrad, but it's been more than 5 years that this opinion was essentially nullified by Okay, If C is "not…

> Okay, If C is "not close to the process", what's closer? LLVM IR is closer. Still higher level than Assembly The problem is thus: char a,b,c; c = a+b; Could not be more different between x86 and ARM

> LLVM IR is closer. Still higher level than Assembly

So your reasoning for repeating the once-fashionable statement is because "an intermediate representation that no human codes in is closer than the source code"?

Re: In Defense of C++

#328

Post by saghm »

jlarocco wrote: post #136
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…

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's not really that big a deal once you know how it works" is the case with pretty much everything though. The question is whether the amount of time needed to learn how something works is worthwhile though, and the sheer number of things you need to invest the time to learn in a language like C++ compared to more modern languages is a big deal. Looking at a single one of them in isolation like the build system essentially just zooms in one problem far enough to remove the other ones from the picture.

Re: In Defense of C++

#329

Post by QuiEgo »

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…

Sending out a strong disagree from the embedded systems world. C is king here.

(Broad, general, YMMV statement): The general C++ arc for an embedded developer looks like this:

1.) discover exceptions are way too expensive in embedded. So is RTTI.

2.) So you turn them off and get a gimped set of C++ with no STL.

3.) Then you just go back to C.

Re: In Defense of C++

#330

Post by saghm »

pjmlp wrote: post #304
imtringued wrote: post #230

Earlier quoted context omitted.

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 would rather deal with Makefiles than Gradle.

I think we can afford to strive for more than just "not quite the absolute worst" (for however we decide to measure quality).
Post reply on HN