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.
How do I deal with memory leaks? (2022)
11–20 of 76 posts
Re: How do I deal with memory leaks? (2022)
#12Good 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).
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)
#13Good 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.
Re: How do I deal with memory leaks? (2022)
#14Re: How do I deal with memory leaks? (2022)
#15Good 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…
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)
#16Strange to see std::sort(), auto_ptr and RAII on the same page, when that combination was always broken.
Re: How do I deal with memory leaks? (2022)
#17Earlier 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.
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)
#18Re: How do I deal with memory leaks? (2022)
#19Strange 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?
Re: How do I deal with memory leaks? (2022)
#20Earlier 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…