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.

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+"+";

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".

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.