How do I deal with memory leaks? (2022) • Hacker News Board

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

#21

Post by eska » Fri, May 08, 2026, 7:11 PM UTC

Panzerschrek wrote: post #17

eska wrote: post #11

Earlier quoted context omitted.

The C++ standard library interface is broken regarding its abstraction of allocation (according to its authors). Therefore you in fact can’t just use arenas in C++ without giving up on large parts of its standard library and becoming incompatible with other code. The languages whose users you call strange don’t have this issue.

I think it's a reasonable price to have your own containers (vector/unique_ptr replacements), if you wish to use a non-standard approach for memory allocation. Many people do this, like Qt with QVector. But do you really need arenas? Does doing allocations in a traditional way creates a bottleneck in your specific use-case? Or you just want to justify broad manual memory management (with its bugs and secure vulnerabi…

Respectfully, you do not seem to understand this topic well. If the C++ standard library design abstracted memory allocation correctly, you’d still be able to use containers and algorithms and not even notice that their allocation strategy uses the heap, stack, a bump allocator, a pool, etc

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

#22

Post by thangalin » Fri, May 08, 2026, 7:15 PM UTC

In raw C, I like to use the "open"/"close" metaphor and when developing, invoke the routes in parallel. For example:

https://repo.autonoma.ca/repo/mandelbrot/blob/HEAD/main.c

When writing:

    fractal.image = image_open( fractal.width, fractal.height );

I will immediately write below it:

    image_close( fractal.image );

This hides memory allocations altogether. As long as the open/close functions are paired up, it gives me confidence that there are no inadvertent memory leaks. Using small functions eases eyeballing the couplings.

For C++, developing a unit test framework based on Catch2 and ASAN that tracks new/delete invocations is rather powerful. You can even set it up to discount false positives from static allocations. When the unit tests exercise the classes, you get memory leak detection for free.

(I don't mind down votes, but at least reply with what you don't like about this approach, and perhaps suggest a newer approach that we can learn from; contribute to the conversation, please.)

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

#23

Post by tombert » Fri, May 08, 2026, 7:19 PM UTC

eska wrote: post #19

tialaramex wrote: post #16

Earlier quoted context omitted.

I actually don't know (at least I don't think I do) the full story here, can you elaborate?

auto_ptr was so misdesigned, they erased it from the language in a later standard. The problem was that the assignment operator “T x = y;” is supposed to have copy semantics, but auto_ptr gave it move semantics by overwriting the source to destroy that reference. This broke all sorts of code that rightfully assumed assignment is done by copying. Therefore all kinda of algorithms like sort broke, as well as resource m…

Me neither.

I have some very smart friends who think it's the perfect language, but I kind of prefer almost every language that has come out after C++. I feel like the language adds some very strange semantics in some very strange places that can be hard to reason about until you've spent a lot of time with the language. This wouldn't necessarily be so bad if not for the fact that most people who write C++ have not spent sufficient time to understand it (and I consider myself in that group, though I don't write C++).

I have mixed feelings on D, but I'm very grateful that Rust came along. Rust is arguably even more complicated than C++, but the good thing is that getting a lot of these complications wrong will simply not allow your code to compile. It's a huge pain in the ass at first but I've become grateful for it.

I still write C very occasionally, but Rust has supplanted like 95% of jobs that were formerly C. I still really need to play with Zig.

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

#24

Post by HeliumHydride » Fri, May 08, 2026, 7:19 PM UTC

eska wrote: post #19

tialaramex wrote: post #16

Earlier quoted context omitted.

I actually don't know (at least I don't think I do) the full story here, can you elaborate?

auto_ptr was so misdesigned, they erased it from the language in a later standard. The problem was that the assignment operator “T x = y;” is supposed to have copy semantics, but auto_ptr gave it move semantics by overwriting the source to destroy that reference. This broke all sorts of code that rightfully assumed assignment is done by copying. Therefore all kinda of algorithms like sort broke, as well as resource m…

auto_ptr was effectively split into std::unique_ptr and std::shared_ptr. The problem was that before C++11, there wasn't a way to distinguish between copy assignment and move assignment.

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

#25

Post by shmolyneaux » Fri, May 08, 2026, 7:20 PM UTC

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 new language that the dev community was seeing for the first time. It's hard to imagine it gaining much traction.

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

#26

Post by Panzerschrek » Fri, May 08, 2026, 7:20 PM UTC

deburo wrote: post #20

Panzerschrek wrote: post #17

Earlier quoted context omitted.

I think it's a reasonable price to have your own containers (vector/unique_ptr replacements), if you wish to use a non-standard approach for memory allocation. Many people do this, like Qt with QVector. But do you really need arenas? Does doing allocations in a traditional way creates a bottleneck in your specific use-case? Or you just want to justify broad manual memory management (with its bugs and secure vulnerabi…

Isn't using Arena just simplifying memory management, thereby reducing the amount of bugs as well?

Use-after-free bugs are still possible, if an allocated memory chunk outlives the arena instance used for it. With C++-style owning containers such kind of errors is possible too, but it's not so frequent.

But arenas can't be used in any case. They are suitable only if large amounts of allocations take place once and need to be deallocated all at once. If reallocation of freeing of individual memory chunks is needed, arenas can't be used, so, it's needed to manage each allocation individually, for which containers is a better choice compared to manual memory management.

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

#27

Post by eska » Fri, May 08, 2026, 7:24 PM UTC

HeliumHydride wrote: post #24

eska wrote: post #19

Earlier quoted context omitted.

auto_ptr was so misdesigned, they erased it from the language in a later standard. The problem was that the assignment operator “T x = y;” is supposed to have copy semantics, but auto_ptr gave it move semantics by overwriting the source to destroy that reference. This broke all sorts of code that rightfully assumed assignment is done by copying. Therefore all kinda of algorithms like sort broke, as well as resource m…

auto_ptr was effectively split into std::unique_ptr and std::shared_ptr. The problem was that before C++11, there wasn't a way to distinguish between copy assignment and move assignment.

Correct. But the C++ language is not a language in which one should just say “screw it” and overload the assignment operator of all things while breaking its contract. Stuff like this is why many purists argue that operator overloading shouldn’t be a thing, because it can lead to shenanigans like this.

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

#28

Post by Panzerschrek » Fri, May 08, 2026, 7:25 PM UTC

eska wrote: post #21

Panzerschrek wrote: post #17

Earlier quoted context omitted.

I think it's a reasonable price to have your own containers (vector/unique_ptr replacements), if you wish to use a non-standard approach for memory allocation. Many people do this, like Qt with QVector. But do you really need arenas? Does doing allocations in a traditional way creates a bottleneck in your specific use-case? Or you just want to justify broad manual memory management (with its bugs and secure vulnerabi…

Respectfully, you do not seem to understand this topic well. If the C++ standard library design abstracted memory allocation correctly, you’d still be able to use containers and algorithms and not even notice that their allocation strategy uses the heap, stack, a bump allocator, a pool, etc

I understand how C++ standard containers are designed. They are designed in such a way, so that they don't store a pointer to an allocator instance inside. This allows to save memory in the most cases (where the standard allocator is used). Overriding an allocator is possible, but only with some another global allocator (via a template argument), with no possibility to specify a per-object allocator.

As I know in newer C++ standards there is something which allows to workaround this issue. Or at least there are proposals for this.

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

#29

Post by eska » Fri, May 08, 2026, 7:27 PM UTC

tombert wrote: post #23

eska wrote: post #19

Earlier quoted context omitted.

auto_ptr was so misdesigned, they erased it from the language in a later standard. The problem was that the assignment operator “T x = y;” is supposed to have copy semantics, but auto_ptr gave it move semantics by overwriting the source to destroy that reference. This broke all sorts of code that rightfully assumed assignment is done by copying. Therefore all kinda of algorithms like sort broke, as well as resource m…

Me neither. I have some very smart friends who think it's the perfect language, but I kind of prefer almost every language that has come out after C++. I feel like the language adds some very strange semantics in some very strange places that can be hard to reason about until you've spent a lot of time with the language. This wouldn't necessarily be so bad if not for the fact that most people who write C++ have not s…

Sounds like you would appreciate this talk: https://m.youtube.com/watch?v=wo84LFzx5nI&pp=ygUSVGhlIGJpZyB...

Personally I use C or something, anything other than C++ really, if I need something more ergonomic or provably correct. Many excuse C++’s design history with “they didn’t know better”, but the oft forgotten history explained in that video shows otherwise.

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

#30

Post by csb6 » Fri, May 08, 2026, 7:27 PM UTC

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…

The FAQ was mostly written before C++11 with some updates since then. I don't think he is rewriting every code snippet to match modern styles. It is an enormous FAQ and not meant as an introduction to the language.