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

411–420 of 470 posts

Re: In Defense of C++

#411

Post by sunshowers »

fluoridation wrote: post #199
sunshowers wrote: post #182

Earlier quoted context omitted.

The ergonomics matter a lot. Of course a lambda is equivalent to a functor that stores a local reference, but making errors with lambdas requires disturbingly little friction. In any case, if you want safety and performance, use Rust.

>making errors with lambdas requires disturbingly little friction Not any less than other parts of the language. If you capture by reference you need to mind your lifetimes. If you need something more dynamic then capture by copy and use pointers as needed. It unfortunate the developer who introduced that bug you mentioned didn't keep that in mind, but this is not a problem that lambdas introduced; it's been there al…

So you agree that modern C++ adds new ways to introduce memory unsafety?

Re: In Defense of C++

#412

Post by einpoklum »

jandrewrogers wrote: post #91
beej71 wrote: post #79

It doesn't mention the horrific template error messages. I'd heard that this was an area targeted for improvement a while ago... Is it better these days?

Qualitatively better. C++20 'concepts' obviated the need for the arcane metaprogramming tricks responsible for generating the vast majority of that template vomit. Now you mostly get an error to the effect of "constraint foo not satisfied by type bar" at the point of use that tells you specifically what needs to change about the type or value to satisfy the compiler.

> C++20 'concepts' obviated the need for the arcane metaprogramming tricks responsible for generating the vast majority of that template vomit.

1. Somewhat exaggerated claim. It reduced that need; and for when you can assumpe everyting is C++20 or later.

2. Even to the extent the need for TMP was obviated in principle - it will take decades for TMP to go away in popular libraries and in people's application code. At that time, maybe, we would stoopp seeing these endless compliation artifacts.

Re: In Defense of C++

#414

Post by QuiEgo »

magnushiie wrote: post #404
QuiEgo wrote: post #329

Earlier quoted context omitted.

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.

Skype was written without exception handling and RTTI, although using a lot of C++ features. You can write good C++ code without these dependencies. You don't use STL but with cautious use of hand-built classes you go far. Today I wouldn't recommnend Skype built in any language except Rust. But the Skype founders Ahti Heinla, Jaan Tallinn and Priit Kasesalu found exactly the right balance of C and C++ for the time. I…

Sure, you absolutely can use a limited set of C++, and find value, and there are many big projects that have gone that route.

See Embedded C++ - https://en.wikipedia.org/wiki/Embedded_C%2B%2B

Apple's IO Kit (all kernel drivers on macOS/iphoneOS/ipadOS/watchOS) is a great example of what you're talking about. Billions of devices deployed with code built on this pattern.

That said, in the embedded world, when you get down to little 32-bit or 16-bit microcontrollers, not amd64 or aarm64 systems with lots of RAM, pure C is very prevelant. Many people don't find much value from classes when they are writing bare-metal code that primarily is twiddling bits in registers, and they also can't or don't want to pay the overhead for things like vtables when they are very RAM constrained (e.x. 64kbyte of RAM is not that uncommon in embedded).

So, I disagree with the idea that "actual uses of C are esoteric" from the post - it's very prevelant in the embedded space still. Just want people to think about it from another use case :).

The classic example of a big pure-C project at scale is the Linux kernel.

Ask Linus what he thinks of C++. His opinions are his own (EDIT: I actually like C++ a lot, please don't come at me with pitchforks! :)), I merely repost for entertainment value (from a while back):

https://lwn.net/Articles/249460/

Maybe a simpler example: go find a BSP (board support package) for the mirco of your choice. It's almost certain that all of the example code will be in C, not C++. They may or may not support building with g++, but C is the lingua franca of embedded devs.

Re: In Defense of C++

#415

Post by [deleted] »

magnushiie wrote: post #404
QuiEgo wrote: post #329

Earlier quoted context omitted.

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.

Skype was written without exception handling and RTTI, although using a lot of C++ features. You can write good C++ code without these dependencies. You don't use STL but with cautious use of hand-built classes you go far. Today I wouldn't recommnend Skype built in any language except Rust. But the Skype founders Ahti Heinla, Jaan Tallinn and Priit Kasesalu found exactly the right balance of C and C++ for the time. I…

[deleted]

Re: In Defense of C++

#416

Post by fluoridation »

sunshowers wrote: post #411
fluoridation wrote: post #199

Earlier quoted context omitted.

>making errors with lambdas requires disturbingly little friction Not any less than other parts of the language. If you capture by reference you need to mind your lifetimes. If you need something more dynamic then capture by copy and use pointers as needed. It unfortunate the developer who introduced that bug you mentioned didn't keep that in mind, but this is not a problem that lambdas introduced; it's been there al…

So you agree that modern C++ adds new ways to introduce memory unsafety?

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.

Re: In Defense of C++

#417

Post by fluoridation »

einpoklum wrote: post #407
fluoridation wrote: post #400

Earlier quoted context omitted.

>So, it's not that "all languages" are like that. That seems like a "moving the goalpost" type of logical fallacy. I think what's mean is that Rust's type system only removes one specific kind of unsafety, but if you're clueless you can still royally screw things up, in any language. No type system can stop you from hosing a database by doing things in the wrong order, say. Whether trading for that additional safety…

> only removes one specific kind of unsafety the word "only" doesn't really belong in that sentence, because these are very common in root-cause analysis of flaws by the "Common Weakness Enumeration" initiative: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html and having said that - I agree with you back :-) ... in fact, I think this is basically "the plan" for C++ regarding security: They'll make some st…

Sure, but those are lists of weaknesses, not of bugs. Of course most of them would be memory errors. A program can play entirely by the rules and still display incorrect behavior. Consider for example the Mars Climate Orbiter bug. No amount of memory safety could have prevented that (although C++ could have been able to encode the unit information in its type system).

Re: In Defense of C++

#418

Post by scrubs »

rapidlua wrote: post #395
scrubs wrote: post #262

Earlier quoted context omitted.

I agree -- I've been at it long enough -- cmake etc makes stuff pretty darn easy. But in industrial settings where multi groups share and change libs something like debpkg may be used. You add caching and you can go quite deep quickly esp after bolting on cdci. One must cop to the fact that a go build or zig build is just fundamentally better.

Go build is fundamentally better? How so? Go build is so light on features that adding generated files to source control is a norm in go land.

Generated files are noise.

Newer languages builds have built in version resolution to resolve dependencies together with smarter ways to reference dependencies without #include.

And that's better

Re: In Defense of C++

#419

Post by [deleted] »

QuiEgo wrote: post #414
magnushiie wrote: post #404

Earlier quoted context omitted.

Skype was written without exception handling and RTTI, although using a lot of C++ features. You can write good C++ code without these dependencies. You don't use STL but with cautious use of hand-built classes you go far. Today I wouldn't recommnend Skype built in any language except Rust. But the Skype founders Ahti Heinla, Jaan Tallinn and Priit Kasesalu found exactly the right balance of C and C++ for the time. I…

Sure, you absolutely can use a limited set of C++, and find value, and there are many big projects that have gone that route. See Embedded C++ - https://en.wikipedia.org/wiki/Embedded_C%2B%2B Apple's IO Kit (all kernel drivers on macOS/iphoneOS/ipadOS/watchOS) is a great example of what you're talking about. Billions of devices deployed with code built on this pattern. That said, in the embedded world, when you get d…

[deleted]

Re: In Defense of C++

#420

Post by sunshowers »

fluoridation wrote: post #416
sunshowers wrote: post #411

Earlier quoted context omitted.

So you agree that modern C++ adds new ways to introduce memory unsafety?

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.

Post reply on HN