title: std::string with no free store memory allocation
body: <p>I have a question very similar to </p>
  
  <p><a href="https://stackoverflow.com/questions/783944/how-do-i-allocate-a-stdstring-on-the-stack-using-glibcs-string-implementation">How do I allocate a std::string on the stack using glibc&#39;s string implementation?</a></p>
  
  <p>but I think it's worth asking again.</p>
  
  <p>I want an <code>std::string</code> with local storage that overflows into the free store. <code>std::basic_string</code> provides an allocator as a template parameter, so it seems like the thing to do is to write an allocator with local storage and use it to parameterize the <code>basic_string</code>, like so:</p>
  
  <pre><code>std::basic_string&lt;
  char, 
  std::char_traits&lt;char&gt;, 
  inline_allocator&lt;char, 10&gt; 
  &gt; 
  x("test");
  </code></pre>
  
  <p>I tried to write the <code>inline_allocator</code> class that would work the way you'd expect: it reserves 10 bytes for storage, and if the <code>basic_string</code> needs more than 10 bytes, then it calls <code>::operator new()</code>. I couldn't get it to work. In the course of executing the above line of code, my GCC 4.5 standard string library calls the copy constructor for <code>inline_allocator</code> 4 times. It's not clear to me that there's a sensible way to write the copy constructor for <code>inline_allocator</code>.</p>
  
  <p>In the other StackOverflow thread, Eric Melski provided this link to a class in Chromium:</p>
  
  <p><a href="http://src.chromium.org/svn/trunk/src/base/stack_container.h" rel="nofollow noreferrer">http://src.chromium.org/svn/trunk/src/base/stack_container.h</a></p>
  
  <p>which is interesting, but it's not a drop-in replacement for <code>std::string</code>, because it wraps the <code>std::basic_string</code> in a container so that you have to call an overloaded <code>operator-&gt;()</code> to get at the <code>std::basic_string</code>.</p>
  
  <p>I can't find any other solutions to this problem. Could it be that there is no good solution? And if that's true, then are the <code>std::basic_string</code> and <code>std::allocator</code> concepts badly flawed? I mean, it seems like this should be a very basic and simple use case for <code>std::basic_string</code> and <code>std::allocator</code>. I suppose the <code>std::allocator</code> concept is designed primarily for pools, but I think it ought to cover this as well.</p>
  
  <p>It seems like the rvalue-reference move semantics in C++0x might make it possible to write <code>inline_allocator</code>, if the string library is re-written so that <code>basic_string</code> uses the move constructor of its allocator instead of the copy constructor. Does anyone know what the prospect is for that outcome?</p>
  
  <p>My application needs to construct a million tiny ASCII strings per second, so I ended up writing my own fixed-length string class based on <code>Boost.Array</code>, which works fine, but this is still bothering me.</p>