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

How do I deal with memory leaks? (2022)

stroustrup.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: How do I deal with memory leaks? (2022)

#61

Post by tombert »

asa400 wrote: post #55
tombert wrote: post #44

Earlier quoted context omitted.

I think there are certainly different complications in Rust than C++. The RAII can be roughly the same in the naive sense, but there's having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff. Gauging how "complicated" a language is somewhat subjective, so it's kind of hard for me to give a straightforward answer. I think it's certainly easier to be (some definition of)…

> having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff. To be fair, the alternative to having to worry about Send/Sync/Pin is not "not worrying about Send/Sync/Pin". It's having to worry about correctly enforcing the constraints they describe on your own, without any kind of mechanical help. E.g., not moving data to another thread that shouldn't be and not accessing…

I don't disagree; I was coming from Java most recently, and a lot of the equivalents of "Sync" and "Send" were just mental notes I was making myself, and I wasn't really used to it being encoded into the type system.

Re: How do I deal with memory leaks? (2022)

#62

Post by jlarocco »

stephbook wrote: post #58

> How do I deal with memory leaks? > plug in a garbage collector. Love it!

I don't know. Bjarne's has been saying for 40 years that C++ will eventually have opt-in garbage collectors written for it, but after all this time I don't think one exists yet unless you count C++/CLI.

For example, the 1987 edition of "The C++ Programming Language" (only 328 pages, including the index!) explains how the user can handle `new` failures with `set_new_handler` to "plug in" a garbage collection function that frees up memory and handles the failure.

And section 10.7 of "The Design and Evolution of C++", is titled "Automatic Garbage Collection", and covers in depth his reasons for not including a garbage collector, and explains a bit about how a plugin automatic collector might work. The TL;DR is that the hardware of the time was too limited and the performance overhead would have killed C++'s chances in its target market. He also posits that memory leaks "are quite acceptable" in many applications because most don't have to run forever and aren't "foundation libraries', but he's probably changed his mind on that by now.

Re: How do I deal with memory leaks? (2022)

#63

Post by eska »

my-next-account wrote: post #45
eska wrote: post #33

Earlier quoted context omitted.

All of this is false. 1) An allocated memory chunk cannot outlive its arena (leaks are impossible). You probably mean a stale reference? The arena is put at such a level in the memory hierarchy that this bug becomes impossible. The bug here would be that the allocation was done in the wrong arena. In C this would be avoided by putting temporary arenas in a local function scope by passing them as parameters. Fool proo…

1) In practice, this is not true, especially if you implement unwinding in your arena. You probably don't want to have an Arena in main, and you do all of your allocations from there, for example. That "just" leaks everything. Here's a classic Arena-with-rewind bug: { Arena a; avec v(a); { RewindMark rm(a); v.push(1); v.push(1); // Trigger resize } v[2] // Oh no! The underlying data array has been deallocated }

I’m sorry, but I look at this code and I can immediately see the bug? Instead of a rewind mark I personally create a local arena from the outer arena. If any allocations leak to the parent scope I put the code in a local function that takes the parent arena as a parameter. Again, if you’re so inclined you can use Rust or C++ to create smart pointers that catch this at runtime or even compile time, it’s just not a real issue for me at this point, reducing the value of complicated compiler machinery leading to bad build times.

Re: How do I deal with memory leaks? (2022)

#64

Post by WalterBright »

jjmarr wrote: post #41
shmolyneaux wrote: post #25

I think more people need to see this. This is how the creator of C++ thinks we should be writing code. This is what he thinks code should look like. To split a string by whitespace we should use `while (cin >> s)`. We should have a `typedef` in the middle of functions. Iterations should use `.begin()` and `.end()` everywhere. There might even be a bug with a trailing "+" appearing in the output? Imagine if this was a…

> Imagine if this was a new language that the dev community was seeing for the first time. It's hard to imagine it gaining much traction. But it's not a new language. It's backwards compatible with C. So "iterators" behave the same as pointers, since that's how you'd iterate through an array. You can add and subtract, then pass them to other functions. You can't just have a function that returns a vector of strings,…

D doesn't allow pointer arithmetic in @safe code. At first it seems like that cannot work, but it works very well. Pointer arithmetic is relegated to functions that are @system.

The reason it works is because D has actual array types.

If you choose to use automatic memory management with D, you are memory safe.

Re: How do I deal with memory leaks? (2022)

#65

Post by desecratedbody »

shmolyneaux wrote: post #25

I think more people need to see this. This is how the creator of C++ thinks we should be writing code. This is what he thinks code should look like. To split a string by whitespace we should use `while (cin >> s)`. We should have a `typedef` in the middle of functions. Iterations should use `.begin()` and `.end()` everywhere. There might even be a bug with a trailing "+" appearing in the output? Imagine if this was a…

[dead]

Re: How do I deal with memory leaks? (2022)

#66

Post by stackghost »

stephbook wrote: post #58

> How do I deal with memory leaks? > plug in a garbage collector. Love it!

You can leak memory in Go, C#, and Java (all GC'ed languages) too. In fact, I've done it.

The real trick, in my experience, is to design your software with things like bounded queues or ring buffers, and to avoid manual memory management (new/delete). This works in C++ just as well as GC'ed languages.

One of my favorite consequences of LLM-heavy workflows (vibe-coding "make me a CRUD app"-style prompts aside) is that prompting the LLM forces the user to put at least a modicum of thought into how the software is actually architected.

Re: How do I deal with memory leaks? (2022)

#67

Post by canucker2016 »

my-next-account wrote: post #40
materielle wrote: post #36

Earlier quoted context omitted.

If you want a laugh, Google a tutorial for how to read a file. You should also know that all the tutorials are wrong, because they fail to handle at least one footgun or another. There is no “modern” alternative. If you read Reddit threads, C++ programmers actually believe that it’s a reasonable file reading API. Most companies that I’ve worked at have just implemented our own on top of the OS syscalls. Which is anno…

C++ has a filesystem API? TIL, never used it.

filesystem api was introduced in C++17

Re: How do I deal with memory leaks? (2022)

#68

Post by Georgelemental »

tialaramex wrote: post #57
tombert wrote: post #44

Earlier quoted context omitted.

I think there are certainly different complications in Rust than C++. The RAII can be roughly the same in the naive sense, but there's having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff. Gauging how "complicated" a language is somewhat subjective, so it's kind of hard for me to give a straightforward answer. I think it's certainly easier to be (some definition of)…

> I do sometimes miss how utterly simple and dumb C is You can make an argument that the K&R C "is" an utterly simple and dumb language, but if it was it's long gone and it's also irrelevant for modern hardware. Today because C only has a single kind of reference, the raw pointer, that means if you want references at all (which you do) you need pointers, and to get decent performance from this sort of language you ne…

To be fair, it's a very hard problem. Even in Rust, the formal model of how provenance works is very much WIP

Re: How do I deal with memory leaks? (2022)

#69

Post by dreamcompiler »

> plug in a garbage collector.

Garbage collectors don't guarantee the absence of memory leaks. GCs remove one important source of memory leaks but it's still very possible in GC languages to use up all available memory unintentionally simply by holding onto things in a big data structure that you've forgotten about (often it's a cache). Weak pointers in conjunction with GC help a great deal with that problem but even so GC and weakness are not going to guarantee leak-prevention in all cases.

I still strongly prefer GC languages to the alternative.

Re: How do I deal with memory leaks? (2022)

#70

Post by jffhn »

stackghost wrote: post #66
stephbook wrote: post #58

> How do I deal with memory leaks? > plug in a garbage collector. Love it!

You can leak memory in Go, C#, and Java (all GC'ed languages) too. In fact, I've done it. The real trick, in my experience, is to design your software with things like bounded queues or ring buffers, and to avoid manual memory management (new/delete). This works in C++ just as well as GC'ed languages. One of my favorite consequences of LLM-heavy workflows (vibe-coding "make me a CRUD app"-style prompts aside) is that…

Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues).

The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).

Post reply on HN