Hacker News new | ask | show | jobs
by pistachiopro 1489 days ago
As a longtime C++ programmer, my view is that that manual memory management is a discipline that you can learn somewhat easily and then you don't spend a lot of time thinking about it.* <-- Big Asterisk

For many applications, allocations fall into two categories: One, temporary allocations that work well with a stack allocator (which is often going to be the main stack where the allocations and deallocations are handled automatically, but sometimes it's useful to have secondary stacks with different lifetimes). And two, larger allocation categories where you can pre-plan access. Many many things can just be allocated statically, others can be allocated from simple pools, and maybe a few things will need complex pools, or even compacting allocators where you end up using smart pointers or smart handles to track them. Once you're used to programming this way, figuring out allocators usually isn't where you spend most of your time. (And as others have said in this thread, if performance is a concern, you spend the same amount of time thinking about this stuff in managed languages, as well.)

* The Big Asterisk is that it's hard to program this way 100% correctly. While it's not hard to get code that works 99.999% of the time for normal usage, it's very hard to make sure nothing in your manually memory managed code is exploitable. Rust, for instance, adds a bunch of language features to fix this issue, and that's one interesting way to go. I do wonder, however, if for many applications it won't turn out that the sandboxing model of something like WASM is more productive. You can still code everything in good ol' C++, but the worst an exploiter can do is hit the edge of the sandbox and crash your application, instead of pwning the user's system.

1 comments

> but the worst an exploiter can do is hit the edge of the sandbox and crash your application, instead of pwning the user's system.

That is still exploitable. Let’s say you have a web app and the js code interacts with the wasm output - if the latter is exploitable, js code may be as well and it can be catastrophic if it is some deeply personal thing, or your bank account. And that can all be controlled by data alone, e.g. if it is a PDF converter or something.