I had heard of the concept of a small buffer optimization for strings where the chars for a really short string are stored directly in the space that the pointer would be. This allows for not actually heap allocating until you are sure you need more than that fixed size. I liked this idea and wanted to take it a step farther and find a real life use case for it. What I decided I wanted was a std::vector that I could hint at it how many elements it was probably going to have be it's max capacity, and then it would secretly just use the stack until it needed more than that capacity. What I ended up with was a fairly complete std::vector like API that does just that!
In many cases, you can just replace std::vector with sbo::array and everything works as expected! There are some holes in the API that you may run into, like the missing reverse iterators, or the inability to use a custom allocator, but I didn't need those at the time I made this, so I just pushed it aside for now. After passing in the template type, you can add an integer size value for how many elements of this should I store on the stack. (Which also determines the sbo::array object size for usage) By default it is set to 256 items, because I most often use this for things like pointers and ids, so I can trust the stack to not be upset about essentially doing this... Entity* ids[256]. Currently, I just usually have it report when these arrays overflow into the heap storage and then print that out at shutdown. Most of the time it says 0% overflowed because I am able to react to that while developing and increase size of an array somewhere, or switch to some other form of storage like a regular vector or retrieving pointers from some sort of longer term storage system like an ECS. I was able to use this to keep the priority queue on my first ever A star to be entirely on the stack by using this with 256 ptr nodes as my container. Internally, this whole thing runs on a union between an char[] and a T*. The template checks at compile time if the T type is plain old data, and that allows for some optimizations with moving data rather than copying using if constepxr blocks. The array will check on push if you are exceeding the stack limit and will pay the price of having to move all the data into the newly allocated pointer, then will continue to reallocate and move when needed as it exceeds limits.
I have also taken a stab at creating an sbo:string_builder class, but it is still being figured out! (The cool part for that one, is a similar method using a local stack block, but its a linked list of char[N] where the root link is built into the struct itself)