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).
cat += *p+"+";
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<u8> 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".
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 += "+";
Since C++11 it is permissible to write stateful memory allocators including arena based memory allocators. You can even write memory allocators that are tied to a specific object, so called sticky allocators.
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?
Also, with allocators you can replace new and delete, but you can't implement anything that doesn't fit into the new/delete paradigm, like any allocation strategy that requires moving objects.
As I know in newer C++ standards there is something which allows to workaround this issue. Or at least there are proposals for this.
C++ added polymorphic memory allocators in C++17 along with polymorphic versions of all standard library containers under the std::pmr namespace, so that you have std::pmr::vector, std::pmr::map, etc... all of which fully abstract out the details of memory allocation.
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.
It's fairly straightforward to compose memory arenas with a pool allocator in these circumstances.
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 proof references require C++ smart pointers. This is one example of you mixing concepts. Smart pointers/containers can still be used with arenas.
2) You mix up arenas and bump allocators. An arena can also use a pool allocator for example. Arena refers to the concept of scoping blocks of allocations.
3) Individual deallocations and arenas are not exclusive, for example using pools. But even with bump allocators free lists are a thing (and linked lists are more attractive in bump allocators because of locality).
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<int> v(a);
{
RewindMark rm(a);
v.push(1); v.push(1); // Trigger resize
}
v[2] // Oh no! The underlying data array has been deallocated
}Generally, it's best to avoid the rewind trick, IMO, it makes it difficult to create composable programs.