Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us (2019)

alexgaynor.net

Post reply on HN
Print view View original

121–130 of 266 posts

Re: Modern C++ Won't Save Us (2019)

#121

Post by adwn »

DethNinja wrote: post #76

I love C++ and I’ve to admit that it will need a subset language soon but the examples given in this article wouldn’t possibly exist in well checked code-bases because you can immediately see usage stinks just by looking at it. I think every C++ is bad article can be summarised like this: 1. C++ has lots of features. 2. Let’s nonsensically combine these features to shoot ourselves on the foot. 3. Uh oh, C++ didn’t he…

> People have to accept that in real life there is a thing called code-reviews and senior engineers are supposed to prevent such badly written code.

Ah, yes, the "you're holding it wrong" argument, just like the article predicted. The problem with this is that your version of "real life" is significantly different from the real "real life", in which often no code-review is held, or the reviewer misses bugs.

Re: Modern C++ Won't Save Us (2019)

#122

Post by jandrewrogers »

01100011 wrote: post #109
jandrewrogers wrote: post #98

Earlier quoted context omitted.

Not to take away anything from your post, but Go is not a systems language. No language with a mandatory garbage collector can make that claim since it makes some systems code effectively impossible to implement.

I agree, but some people don't. When I interviewed at Google a couple years ago, they were rewriting the Fuchsia network stack in Rust. It was currently written in Go. My jaw about hit the floor when I heard that. I'm guessing they realized it was a mistake, but then again maybe the Go version was just a temporary placeholder. IDK, didn't get the job.

Rust is an entirely adequate systems language for most purposes. I think it could probably replace C for almost all purposes except in cases where extreme portability is required, which C excels at.

C++ is really only the answer if you need extreme performance and/or expressiveness out of a systems language. Some code, like database engines, really benefits from that.

Re: Modern C++ Won't Save Us (2019)

#123

Post by tpoacher »

Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

> As a result, "unsafe" is too often used as an escape hatch when someone can't spend the time to get it right.

Isn't that exactly the same as C++ then?

Re: Modern C++ Won't Save Us (2019)

#124

Post by chriswarbo »

creata wrote: post #27
Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

I'm not sure what you mean by "global analysis," but Rust's borrow checker doesn't do any analysis that I'd consider "global."

The point of the borrow checker is to replace the global property 'all memory has an owner' with the (approximate, conservative) equivalent 'all code passes the borrow checker'.

By tracing ownership information through each component, and forbidding (or ignoring via `unsafe`) situations which cannot be traced in this way, the latter property can be decomposed and solved locally.

In other languages, like C++, we may still want this global property, but we can't break it down into local reasoning. Even if we decide on an approximate, conservative equivalent like 'all code passes STATIC ANALYSER X', getting local reasoning to work would require enough changes that it's arguable whether we're actually programming in the same language anymore. For example, we may need to add extra annotations to our code (which aren't present in existing codebases); we may need to extract extra information from sources (preventing the normal use of separately-compiled libraries); we (and our dependencies!) may need to avoid certain valid/legal patterns of code which the analyser can't handle; etc.

Writing the above, I'm reminded of trying to use the mypy type checker in Python!

Re: Modern C++ Won't Save Us (2019)

#125

Post by ttt0 »

pornel wrote: post #2

UB-invoking dereference in std::optional is such a baffling design choice. The whole point of an optional type is to prevent accidental unchecked access to the value. Sure, sometimes it's useful for performance to skip the check when it's already known-safe from the context, but such dangerous optimization should have been behind a method like `beware_of_the_nasal_demons()`, not an innocent-looking convenience syntax…

As far as I'm considered, the purpose of std::optional is so you don't have to allocate memory on the heap and then check for null pointer. I don't want it to throw exceptions, just like I don't want the language to check the validity of a pointer every time I want to dereference it.

Re: Modern C++ Won't Save Us (2019)

#126

Post by asiachick »

tejohnso wrote: post #59
HexDecOctBin wrote: post #34

Earlier quoted context omitted.

> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…

Wow, Casey doesn't hold back. Clearly, without hesitating says that 100% of code written in RAII* style sucks. Interesting considering Stroustrup considers RAII to be "the basis of some of the most effective modern C++ design techniques." I'd like to hear Casey's comments on TDD. *RAII style is lumped together with try/catch, smart pointers, tons of malloc/free new/delete

Casey hasn't a clue. He's only written games and he hasn't actually had to solve the issues that are being solved by in other domains. If he actually did have that experience he'd see his ideas don't scale. Games are in generally, vastly different than other apps (word processors, video editors, browsers, etc) in for one, for the most part, they get to choose all of their data upfront. If you're making "The Last of Us 2" there is no user data. There's no "some people will use this to write a letter to grandma and yet some other people will write an 800 page book on physics with mathematical diagrams" and yet another will write a report on the market with linked live data.

Re: Modern C++ Won't Save Us (2019)

#127

Post by josefx »

lmm wrote: post #83
jandrewrogers wrote: post #80

Earlier quoted context omitted.

An additional issue is that some sophisticated C++ doesn’t always translate easily into other languages. It isn’t just a fairly direct reimplementation but a legit redesign. That will be a bug factory, especially for the kinds of codes that tend to be difficult to translate, as proving equivalence won’t be trivial.

I'd submit that the kind of code that's difficult to translate - that is, code where it's not clear where the responsibility for the lifecycle of a given piece of memory lies - is already a bug factory.

You haven't known suffering until you tried to rewrite a large C++ codebase in Java. No clear ownership you say? All those members that clearly belong to one object suddenly have to be guarded against accidentally having their references shared, all that clear math code turns into an indecipherable mess and you can forget about lifecycles unless you guard every resource with a try block. Sadly I end up writing Java code from time to time because I can write passable swing UIs faster than I can set up Qt.

Re: Modern C++ Won't Save Us (2019)

#129

Post by 127 »

Here's the point of view from someone who has only written 1 piece of production software with both C++ and Rust.

Trying to write C++ I was constantly fighting accidental memory copies. With Rust all of this was trivial and everything works as I expect. This is pretty much the reason I chose Rust over C++.

As a beginner I have no idea how I would begin to elegantly write immutable data, parallel code. With Rust it's just .iter() to .par_iter() (everything is immutable by default).

C++ package management is awful (it has none). C++ headers are annoying and pointless.

I know these are strong statements and of course only my opinion but I just see people claiming C++ is fine just having a strong case of Stockholm Syndrome.

Rust is nowhere perfect. Often it can look like line noise, the project folder takes multiple gigabytes even for small-ish projects, the compilations can be slow, the tooling is not always there. This is still multiple orders of magnitudes better than trying to Google how Cmake works step by step.

On the other hand I love rustanalyzer + vscode. It was super easy to get going with and just works. Visual Studio C++ seems to be much more steep as a learning curve.

Re: Modern C++ Won't Save Us (2019)

#130

Post by jcelerier »

andyxor wrote: post #81
solipsism wrote: post #63

Earlier quoted context omitted.

What do you call "wisdom" that's passed from person to person, so everyone knows it, but it isn't actually true? A huge amount of Boost is nothing but headers. And it's very easy to use those header-only libraries and avoid the rest. Sure, many people have just pulled in the entirety of Boost... but it's really strange to blame Boost for those bad choices. By the way, a lot of what today is standard C++ had its origi…

well i've seen it used "enthusiastically" for the lack of better word, i.e. once someone on the team starts using one header, with some relatively well proven and robust feature (like smart pointers), it creates a temptation for them and other team members to use anything else available in that giant library "for free". And some features there could be more experimental in nature and some are either not intended, or…

> And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare.

how is that better than the usual 2021 project having a package.json with 350 sub-dependencies

Post reply on HN