[boost] Proposal: Extended Allocators (was Montonic Containers)

Subject: [boost] Proposal: Extended Allocators (was Montonic Containers)
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-06-09 09:49:32

It is my belief (but I'm happy to shown wrong) that the idea of  
'Monotonic Containers' to provide a new allocator for vector to  
support a small block of memory is fundamentally not going to work,  
due to 2 limitations of allocators:

1) There is no support for in-line expansion (effectively, realloc  
which doesn't move if it can't realloc)
2) There is no support for an allocator to say "No, you can't have X  
memory, but I could give you Y", so it's hard to "exactly fill" a  
limited memory buffer.

I have been working around this by implementing new special  
containers, which know about the size of a fixed buffer and therefore  
can make use of the space. I now think I'm probably going about this  
the wrong way, a much better way would be to implement: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html 
  , or a variant thereof.

The big problem with doing this "within boost" is that it would pull  
in a basically complete implementation of std::allocator and the  
containers into boost.

In an ideal world, such a small and in my opinion useful extension  
would have been added to C++0x, but it's far too late for that now.

tl;dr : Seeing as we are having a "what would boost accept" couple of  
days, would adding an (extended) implementation of a substantial part  
of the standard library be acceptable, or would I be better off trying  
to get this picked up by one of the existing standard libraries to  
pick this up (my worry being they may not want, quite sensibly, want  
to accept code which is not standardised).

Chris