title: How can I write a stateful allocator in C++11, given requirements on copy construction?
body: <p>As far as I can tell, the requirements on an allocator to be used with STL
  containers are laid out in Table 28 of section 17.6.3.5 of the C++11 standard.</p>
  
  <p>I'm a bit confused about the interaction between some of these requirements.
  Given a type <code>X</code> that is an allocator for type <code>T</code>, a type <code>Y</code> that is "the
  corresponding allocator class" for type <code>U</code>, instances <code>a</code>, <code>a1</code>, and <code>a2</code> of
  <code>X</code>, and an instance <code>b</code> of <code>Y</code>, the table says:</p>
  
  <ol>
  <li><p>The expression <code>a1 == a2</code> evaluates to <code>true</code> only if storage allocated
  from <code>a1</code> can be deallocated by <code>a2</code>, and vice versa.</p></li>
  <li><p>The expression <code>X a1(a);</code> is well-formed, doesn't exit via an exception,
  and afterward <code>a1 == a</code> is true.</p></li>
  <li><p>The expression <code>X a(b)</code> is well-formed, doesn't exit via an exception, and
  afterward <code>a == b</code>.</p></li>
  </ol>
  
  <p>I read this as saying that all allocators must be copy-constructible in such a
  way that the copies are interchangeable with the originals. Worse, the same
  true across type boundaries. This seems to be a pretty onerous requirement; as
  far as I can tell, it makes impossible a large number of types of allocators.</p>
  
  <p>For example, say I had a freelist class that I wanted to use in my allocator,
  in order to cache freed objects. Unless I'm missing something, I couldn't
  include an instance of that class in the allocator, because the sizes or
  alignments of <code>T</code> and <code>U</code> might differ and therefore the freelist entries are
  not compatible.</p>
  
  <p>My questions:</p>
  
  <ol>
  <li><p>Are my interpretations above correct?</p></li>
  <li><p>I've read in a few places that C++11 improved support for "stateful
  allocators". How is that the case, given these restrictions?</p></li>
  <li><p>Do you have any suggestions for how to do the sort of thing I'm trying to
  do? That is, how do I include allocated-type-specific state in my allocator?</p></li>
  <li><p>In general, the language around allocators seems sloppy. (For example, the
  prologue to Table 28 says to assume that <code>a</code> is of type <code>X&amp;</code>, but some of the
  expressions redefine <code>a</code>.) Also, at least GCC's support is non-conformant.
  What accounts for this weirdness around allocators? Is it just an infrequently
  used feature?</p></li>
  </ol>