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

421–430 of 470 posts

Re: In Defense of C++

#421

Post by fluoridation »

sunshowers wrote: post #420
fluoridation wrote: post #416

Earlier quoted context omitted.

Your question is too broad. I'd have to think about it, but intuitively I'd say no, I don't agree with that. More to the point, lambdas don't introduce any new avenues for memory bugs. Like I said, at the worst they trick inexperienced programmers coming from garbage-collected languages into thinking the platform will deal with lifetimes for them.

The person who introduced the bug was highly competent and had at least 10 years of C++ experience. He was sure he'd gotten it right and himself didn't believe how subtle the bug turned out to be. The people coming from GC languages have the right expectations about the language taking care of lifetimes for them. I expect nothing less than technical excellence from my tooling.

To clarify, I'm not interested in debating the skills of any particular programmer. My sole point is that lambdas didn't bring any new ways of mismatching lifetimes. That programmer could have made the exact same mistake with a functor instead and it wouldn't have changed anything.

>I expect nothing less than technical excellence from my tooling.

Good luck with that.

Re: In Defense of C++

#422

Post by unscaled »

bayindirh wrote: post #280
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…

These type comments always remind me that we forget where we come from in terms of computation, every time. It's important to remember Rust's borrow checker was computationally infeasible 15 years ago. C & C++ are much older than that, and they come from an era where variable name length affected compilation time. It's easy to publicly shame people who do hard things for a long time in the light of newer tools. Howev…

> the processor, which is a glorified, hardware implemented PDP-11 emulator.

This specific seems like just gratuitously rewriting history.

I can get how you'd feel C (and certain dialects of C++) are "closer to the metal" in a certain sense: C supports very few abstractions and with fewer abstractions, there are less "things" between you and "the metal". But this is as far as it goes. C does not represent - by any stretch of imagination - an accurate computational model or a memory of a modern CPU. It does stay close to PDP-11, but calling modern CPUs "glorified hardware emulators of PDP-11" is just preposterous.

PDP-11 was an in-order CISC processor with no virtual memory, cache hierarchy, branch prediction, symmetric multiprocessing and SIMD instruction. Some modern CPUs (namely the x86/x64 family of CPUs) do emulate a CISC ISA on that is probably more RISC-like, but that's as far we can say they are trying to behave like a PDP-11 (even though the intention was to behave like a first-gen Intel Pentium).

Re: In Defense of C++

#423

Post by unscaled »

rramadass wrote: post #373
estimator7292 wrote: post #316

Earlier quoted context omitted.

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…

In practice, C++ is a language family more than a single programming language. Every C++ project I've worked on essentially had its own idiolect of C++.

Re: In Defense of C++

#424

Post by Defletter »

palata wrote: post #405
Defletter wrote: post #385

Earlier quoted context omitted.

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

> Your defensiveness Start by not calling everybody disagreeing with you a cultist, next time. > 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. It's not that it is unclear, it's just that it doesn't make sense. When we compare…

> Start by not calling everybody disagreeing with you a cultist, next time.

You'd do very well as a culture war pundit. Clearly I wasn't describing a particular kind of person, no, I'm clearly I'm just talking about everyone I disagree with /s

Re: In Defense of C++

#425

Post by zbentley »

jcelerier wrote: post #402
zbentley wrote: post #309

Earlier quoted context omitted.

I mean, you kinda do. Otherwise you won’t understand why bit-shifting to std::cout prints something, which is pretty much day 1 of C++ hello world introduction (yes, I know there are introductions that don’t use that silly syntax sugar. They’re rare, like it or not.) Like, sure, you don’t have to understand cout’s implementation of operator That’s … a lot more to learn than, say, printf.

> I mean, you kinda do. Otherwise you won’t understand why bit-shifting to std::cout prints something, but it's not bit-shifting, it's "<<", which can do different operations in different contexts.

…yes, that is what I said people need to understand in operator-overloading-happy environments.

Re: In Defense of C++

#426

Post by rramadass »

unscaled wrote: post #423
rramadass wrote: post #373

Earlier quoted context omitted.

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…

In practice, C++ is a language family more than a single programming language. Every C++ project I've worked on essentially had its own idiolect of C++.

This is just a oft-repeated cliche and nothing more. Because C++ is a multi-paradigm language (with admittedly some less than ideal syntax/semantic choices) people overstate its complexity without much study/experience. Herd mentality than takes over and people start parroting and spreading the canard.

For the power and flexibility that C++ gives you, it is worth one's time to get familiar with and learn to use its complexity.

Re: In Defense of C++

#427

Post by sunshowers »

fluoridation wrote: post #421
sunshowers wrote: post #420

Earlier quoted context omitted.

The person who introduced the bug was highly competent and had at least 10 years of C++ experience. He was sure he'd gotten it right and himself didn't believe how subtle the bug turned out to be. The people coming from GC languages have the right expectations about the language taking care of lifetimes for them. I expect nothing less than technical excellence from my tooling.

To clarify, I'm not interested in debating the skills of any particular programmer. My sole point is that lambdas didn't bring any new ways of mismatching lifetimes. That programmer could have made the exact same mistake with a functor instead and it wouldn't have changed anything. >I expect nothing less than technical excellence from my tooling. Good luck with that.

I've been having great luck expecting technical excellence from Rust and its community, thank you!

Re: In Defense of C++

#428

Post by feffe »

einpoklum wrote: post #372
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 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, w…

CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn.

For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makefile than some obscure 3pp CMake module that doesn't do what I want. Plain old makefiles are very hackable for better or worse [1]. It's easy to solve problems with make (in bespoke ways), and at the same time this is the big issue, causing lots of custom solutions of varying correctness.

[1]: Make is easy the same way C is easy.

Re: In Defense of C++

#429

Post by einpoklum »

dig1 wrote: post #303
loeg wrote: post #45

> in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. This... doesn't really hold water. You have to learn about what the insane move semantics are (and the syntax for m…

> You have to learn about what the insane move semantics are (and the syntax for move ctors/operators) to do fairly basic things with the language That is simply not true. You can write a lot of C++ code without even touching move stuff. Hell, we've been fine without move semantics for the last 30 years :P > Overloaded operators like operator*() and operator Partially true. operator*() is used through the standard li…

> operatorNot that widely. You must be thinking of the IO streams part of the library. Yes, it's rather poor in many respects. But you don't have to use it! We have perfectly nice variadic printing functions these days!

    auto number = 42;
    std::println("Hello, {}! The answer is {}", "world", number);

Re: In Defense of C++

#430

Post by einpoklum »

feffe wrote: post #428
einpoklum wrote: post #372

Earlier quoted context omitted.

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

CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn. For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makef…

I didn't say "easy to deal with", I said it's not bespoke nonsense, and that you could keep it mostly unchanged today, 8 years later.

Plus - the "obscure third party modules" have been getting less obscure and more standard-ish. In 2017 it was already not bad, today it's better.

Post reply on HN