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

141–150 of 266 posts

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

#141

Post by flohofwoe »

asiachick wrote: post #126
tejohnso wrote: post #59

Earlier quoted context omitted.

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

Consider "games" like Minecraft, Roblox or Dreams, those are entirely user-data-driven. Different types of games are at least as different to each other as to other types of applications (or rather, they are not less diverse than other applications, they usually just have a higher focus on performance).

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

#142

Post by gypsyharlot »

jandrewrogers wrote: post #82
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…

I think it is fair to point out that it requires a comparatively high degree of skill and experience to use C++ well relative to many other languages. Most people do not use C++ well because doing so is quite difficult and requires a large investment of time. This is not helped by the fact that it has an enormous amount of legacy baggage that is technically valid code that no one should ever use — there is an entire…

Let's not confuse this with skill, though. I think ego is the reason why this has been allowed to go on for this long...

The "skill" is mainly pointless memorization of a bunch of idioms. I've attended C++ training with committee members that have made C++ their life... and it was quite discouraging to see that even they do: Let's try this... oh, that didn't work. Let's try this... hmm, right. I know what this is, I've seen it before. Now, it works.

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

#143

Post by pjmlp »

echelon wrote: post #139
127 wrote: post #129

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…

C++ is a garbage language. There's literally nothing worse. Not PHP, not Perl, not Bash nor VBScript. C++ is literally the worst language. You have to be an arcane wizard to write safe C++. Your code reviewers have to be all-seeing oracles. You're asked to follow this pattern called RAII, but the language does nothing to tell you this or enforce it. Creating declarations and header files is so ceremonious and tiring…

If an OS vendor was passionate about Modula-3, Ada or Eiffel, Rust wouldn't be needed, but unfortunely other paths were taken.

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

#144

Post by Rochus »

127 wrote: post #129

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…

Well, it's good that you have the choice. Mastering C++ takes many years, and each edition of the standard adds a few hundred pages.

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

#145

Post by HexDecOctBin »

viraptor wrote: post #133
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…

Your comment reads like you disagreed in some way with the parent, but then you showed a scenario and defined it in a way you can answer the important questions. Just drop the "we don't care" part and they're all good answers that can be used to model the ownership and usage. The lack of locks in this scenario is important in itself and can be expressed in types. (It shows for example that as long as the whole proces…

No, the point wasn't a scenario. The point was to stop focussing on individual allocation-deallocation and start thinking about the data transformation pipeline. And every program is a data transformer — because data transformation is all a computer does or can possibly do.

When one starts thinking in terms of data transformation pipeline, and start to relate lifetime of data with the lifetime of various phases of that pipeline, then one stops worrying about individual "objects" and start thinking in terms of aggregates. Suddenly, there is no need to track the ownership or size for each object, because those properties are now shared with the same (or isomorphic) properties of the phases of pipeline itself. As long as the position in the pipeline is tracked for (e.g., the call stack), all other lifetimes will automatically be tracked.

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

#146

Post by pjmlp »

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…

C++ was my passion after Turbo Pascal, I fought to use it instead of C on university assignments, was a TA in C++, did research at CERN in C++, and used it at several multinationals before migrating into managed languages.

Well checked code-based is something that I have hardly seen in real life, outside conference talks about best practices.

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

#147

Post by lmm »

volta83 wrote: post #136
lmm wrote: post #31

Earlier quoted context omitted.

This amounts to saying that we should accept codebases continuing to contain exploitable vulnerabilities indefinitely. Perhaps for codebases that have a finite expiry date that's tolerable, but for a codebase that's expected to be maintained indefinitely I don't see how it can possibly be worthwhile - a rewrite will be a one-time cost, whereas exploitation is an ongoing cost that will surely exceed the one-time cost…

> This amounts to saying that we should accept codebases continuing to contain exploitable vulnerabilities indefinitely. Right, why shouldn't we? I have a CLI application for storing TODOs. It never accesses the network, I don't really care if it crashes, it does not have an expiry daye. I have a constant amount of time to work on it. To me it is more value to put that time into new features that save me a couple of…

If it's a personal app that you're not going to share with others then that app does have a finite expiry, admittedly in a slightly morbid way. I'd submit that an app with a truly stable userbase requires an impossible level of fine tuning - in reality an app is either growing or shrinking.

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

#148

Post by Rochus »

notacoward wrote: post #43
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…

> You allocate a memory arena when the HTTP request comes. The per-request-arena concept is one of the most powerful and IMO underappreciated tools out there for dealing with memory-lifetime issues. I've used it or advocated for its use at multiple jobs and projects, quite successfully, even for kernel code. Windows NT uses it in IRPs. Network code in both BSD and SysV did something pretty similar, at least in the lo…

> Rust's borrow checker plus Zig's arena concept plus a couple more pieces might actually get us there. C++'s feature salad never will.

Looks like there's some new salad growing.

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

#149

Post by vineek »

I completely agree with the points from this article. It is fundamentally infeasible to make all C and C++ code safe. The main reason, PAST code. There are countless lines of unsafe code already written. However, there is nothing magical about Rust's facilities (e.g. borrow checker) that make them inapplicable to FUTURE C and C++ code. I believe this is the only way forward for C and C++. They need to offer mechanisms that guarantee that any code written today can be provably memory and thread safe. That of course requires yet another tool in the myriad of tools that exist for C and C++.

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

#150

Post by pjmlp »

solipsism wrote: post #55
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…

Easily dealt with with a linter. C++ is not fundamentally a safe language. It's fundamentally a no-cost abstraction language. It's not a baffling design choice if you know C++.

Pity that linters isn't something most C++ devs feel like they need.

https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...

Post reply on HN