Live data from Hacker News

How do I deal with memory leaks? (2022)

stroustrup.com

11–20 of 76 posts

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

#11
post #6

Earlier quoted context omitted.

No need to insult people just because you don’t understand other strategies for reducing the amount of lifetimes to track and consolidating deallocations by using memory arenas.

You can use some arena implementation in C++ too. But only when you need such an approach. If you don't care - just use std::string, std::vector or something similar.

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.

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

#12

Good arguments. But for some reason there are still strange people, who prefer calling malloc/free (or new/delete or something similar) manually. Some of them even invent languages with manual-only memory management (like Zig or Odin).

I'm no fan of Odin especially, but I'd expect that one obvious defence they'd offer is that this code potentially wastes a lot of resources and if you were writing in their language you'd more likely go "Wait, that seems like a bad idea..." and produce better code.

    cat += *p+"+";
Feels very cheap because it was so few keystrokes, but what it's actually doing is:

1. Making a brand new std::string with the same text inside it as `p` but one longer so as to contain an extra plus symbol. Let's call this temporary string `tmp`

2. Paste that whole string on the end of the string named `cat`

3. Destroy `tmp` freeing the associated allocation if there is one

Now, C++ isn't a complete trash fire, the `cat` std::string is† an amortized constant time allocated growable array under the hood. Not to the same extent as Rust's String (which literally is Vec inside) but morally that's what is going on, so the appends to `cat` aren't a big performance disaster. But we are making a new string, which means potentially allocating, each time around the loop, and that's the exact sort of costly perf leak that a Zig or Odin programmer would notice here.

† All modern C++ std::string implementations use a crap short string optimisation, the most important thing this is doing - which is the big win for C++ is they can store their empty value, a single zero byte, without allocating but they can all store a few bytes of actual text before allocating. This might matter for your input strings if they are fairly short like "Bjarne" "Stroustrup" and "Fool" but it can't do "Disestablishmentarianism".

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

#13
post #5

Good arguments. But for some reason there are still strange people, who prefer calling malloc/free (or new/delete or something similar) manually. Some of them even invent languages with manual-only memory management (like Zig or Odin).

One reason is that c++ still hasn't gotten 'trivial relocatability' right - i.e being able to memcpy/memmove and not have to call constructors/destructors when growing your vector class.

Actually, issues with non-trivial moves and relocations are specific only for C++. Some other languages (notably Rust and Swift) don't have such issues, but still have nice automatic memory management via destructors and containers atop of it.

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

#15

Good arguments. But for some reason there are still strange people, who prefer calling malloc/free (or new/delete or something similar) manually. Some of them even invent languages with manual-only memory management (like Zig or Odin).

I'm no fan of Odin especially, but I'd expect that one obvious defence they'd offer is that this code potentially wastes a lot of resources and if you were writing in their language you'd more likely go "Wait, that seems like a bad idea..." and produce better code. cat += *p+"+"; Feels very cheap because it was so few keystrokes, but what it's actually doing is: 1. Making a brand new std::string with the same text in…

I agree, having nice containers with automatic memory management allows such problems. But this code still works as intended, but it has suboptimal performance. But I think, that it's still better to use an approach allowing such performance issues, rather then bugs specific for manual memory management (memory leaks, use-after-free errors, spatial access errors).

And it's still possible to improve performance here without returning to manual memory management. Just replace it with something like this:

    cat += *p;
    cat += "+";
Now no temporary string is created and thrown away, only cat performs memory allocations under the hood.

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

#17
post #11

Earlier quoted context omitted.

You can use some arena implementation in C++ too. But only when you need such an approach. If you don't care - just use std::string, std::vector or something similar.

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 vulnerabilities) in hope to gain (or not) a tiny amount of extra performance?

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

#19
post #14

Strange to see std::sort(), auto_ptr and RAII on the same page, when that combination was always broken.

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 management. Suffice to say I am personally not a fan of C++ language design or Stroustrup’s opinions on programming.

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

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

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