[ACCEPTED]-How do I allocate a std::string on the stack using glibc's string implementation?-stack-memory

I wanted to do just this myself recently 25 and found the following code illuminating:

Chronium's stack_container.h

It 24 defines a new std::allocator which can provide stack-based 23 allocation for the initial allocation of 22 storage for STL containers. I wound up 21 finding a different way to solve my particular 20 problem, so I didn't actually use the code 19 myself, but perhaps it will be useful to 18 you. Do be sure to read the comments in 17 the code regarding usage and caveats.

To 16 those who have questioned the utility and 15 sanity of doing this, consider:

• Oftentimes you know a priori that your string has a reasonable maximum size. For example, if the string is going to store a decimal-formatted 32-bit integer,you know that you do not need more than 11 characters to do so. There is no need for a string that can dynamically grow to unlimited size in that case.
• Allocating from the stack is faster in many cases than allocating from the heap.
• If the string is created and destroyed frequently (suppose it is a local variable in a commonly used utility function), allocating from the stack instead of the heap will avoid fragmentation-inducing churn in the heap allocator. For applications that use a lot of memory, this could be a game changer.

Some people 14 have commented that a string that uses stack-based 13 allocation will not be a std::string as if this somehow 12 diminishes its utility. True, you can't 11 use the two interchangeably, so you won't 10 be able to pass your stackstring to functions expecting 9 a std::string. But (if you do it right), you will 8 be able to use all the same member functions 7 on your stackstring that you use now on std::string, like find_first_of(), append(), etc. begin() and 6 end() will still work fine, so you'll be able 5 to use many of the STL algorithms. Sure, it 4 won't be std::string in the strictest sense, but it 3 will still be a "string" in the 2 practical sense, and it will still be quite 1 useful.

The problem is that std::basic_string has a template parameter 8 for the allocator. But std::string is not a template 7 and has no parameters.

So, you could in principle 6 use an instantiation of std::basic_string with an allocator 5 that uses memory on the stack, but it wouldn't 4 be a std::string. In particular, you wouldn't get runtime 3 polymorphism, and you couldn't pass the 2 resulting objects into functions expecting 1 a std::string.

You can't. Except...

std::string is an instantiation 12 of

std::basic_string<class CharType, 
                  class Traits=char_traits<CharType>, 
                  class Allocator=allocator<CharType> >

You could conceivably define an Allocator 11 class that uses alloca for memory management. This 10 would only work if the Allocator itself, and 9 the basic_string methods that invoke it directly or 8 indirectly, are all inline. A basic_string object created 7 with this allocator would not be a std::string, but it 6 would behave (mostly) like it. However, this 5 would be a fair amount of work for limited 4 gains. Specifically, using this class to 3 return values from a function would be a 2 career-limiting move.

I have no idea why you 1 or anyone else would want to do this.

I suspect that doing such a thing would 13 be difficult to do, I wonder why you want 12 to do it? To allocate something entirely 11 on the stack, the compiler needs to know 10 at compile time what the exact size of the 9 thing is - in your example it would need 8 to know not only the size of the std::string metadata, but 7 also the size of the string data itself. This 6 isn't too flexible, you would probably need 5 different string types depending on the 4 size of the string data you are wanting 3 to include in it - not that it would be 2 impossible to do, just it would tend to 1 complicate things up a bit.