Live data from Hacker News

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

alexgaynor.net

201–210 of 266 posts

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

#201
post #175

Earlier quoted context omitted.

I don't see `unsafe` being used as an escape hatch IMO.

Same here, lots of large projects I worked didn't have any unsafe at all. It's a very niche feature, mostly for people doing very low-level stuff. But I suspect this is survivorship bias. I only ever worked with very experienced developers when doing Rust. I'm pretty sure as soon as I start working with more inexperienced devs I'll start seeing a multitude of clever ways to bypass the borrow checker, similar to the c…

It's a feature that's necessary when dealing with FFI or when implementing containers. It's a tool, rather than a crutch to work around the borrow checker. In fact, unless one is using raw pointers everywhere, it's very impractical to use unsafe blocks to circumvent the borrow checker.

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

#203

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…

> From that point on, every "allocation" is equivalent to bumping a pointer in that arena. I'm not a C++ developer, so I have a hard time imagining how would this be implemented in real code. I know how to allocate a blob of memory, but how do I redirect all the later allocations (that use `new` or that are hidden in std::string and other containers) to use parts of that blob? How do I know when the blob is going to…

You either pass the allocator around to every stl container, and everything that uses an stl container. Or you override new/delete and have a sidechannel that defines what arena to allocate in.

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

#204
post #51

I care about speed. Moderm C++ has a giant lot of features, slowly approaching to eclipsing the number of such in Java. I don't know how fast they work, how optimisable they are, and how much memory they eat. Speed is the main quality of a computer program.

Depends what you're working on. That's probably true with games but the most important quality of most programs is maintainability.

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

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

While I agree with most of what you wrote, CMake feels supercharged compared to the build system part of Cargo. Cargo is failing hard on the integration front, both on integrating things, and being integrated. build.rs is a minimal substitute of a build system: "deal with it yourself". The way Cargo wants to have total control, on the other hand, makes it hard to integrate with existing projects: those which don't us…

Cargo is a package manager first and minimum viable build system in far second. Comparing it to CMake is a bit unfair.

If you need a real build system use cargo make or CMake itself.

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

#207

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

I wonder, has Bjarne Stroustrup even shipped any industrial-grade software? Because he's mostly an academic AFAIK.

Edit - Already answered in more detail, below.

He is at Morgan Stanley,

https://www.morganstanley.com/profiles/bjarne-stroustrup-man...

I don’t know how close he is to the grind, but I imagine he at least talks to people who are reasonably often.

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

#208

Earlier quoted context omitted.

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

I'm pretty confident Minecraft, Roblox, and Dreams are not following Casey's practices.

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

#209

Earlier quoted context omitted.

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

I'm pretty confident Minecraft, Roblox, and Dreams are not following Casey's practices.

What makes you say that?

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

#210

Earlier quoted context omitted.

I have no idea what "industrial grade software is", but I ship a cross-platform DAW written in C++, and RAII is tremendously awesome.

Are you saying that it is better than the alternatives? Have you tried writing code from a grouped-resources perspective? What was your conclusion?

I don't see grouped resources as an alternative to the way we use RAII. It doesn't mean that the approach doesn't have its own merits, but it doesn't cover the things we do with RAII. The architecture of a DAW isn't much like a server that responds to requests, even if there are elements of it that do correspond to that pattern.

Alternatively, you are referring to something I'm not aware of.

Post reply on HN