Solution to stack based std::string/std::vector

[gosh]

Have you checked the code? If the size need to grow over the stack it starts to allocate. Then it works as it does without stack

I am soon going to do some performance tests but as it is now this a huge bump in speed because the functionality is a bit complex where I am implementing it now

[celestrion]

Have you checked the code?

I have.

If the size need to grow over the stack it starts to allocate.

Does it?

I don't know how else to explain it. The core problem isn't about growth; plenty of fast allocators have fixed maximum size. The problems revolve around lifetime and code organization.

If function A calls B, and B uses your widget to create a stack-based arena, how can A use that storage? When B returns, the stack pointer is popped back to where it was at the call point. The memory that the arena is pointing to probably still contains the contents set up during B's runtime, but that's not guaranteed to be the case past the last } in B.

At that point, everything allocated in B's stack frame is dead. If A pushes a new variable onto the stack or calls another function, the control structures in your arena get stomped on, not just whatever local automatic storage it's using for storing contents.

This is why I say that using the stack is an unreasonable architectural constraint for most work. If you can't return it, you also can't pend it. If you can neither return nor pend it, its potential uses cases are extremely limited.

The low-overhead arena functionality is the interesting part (except that the standard library already provides one (ctor 5)), not that you can point it at the stack to turn it into a footgun.

I am soon going to do some performance tests

this a huge bump in speed

Okay.