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

Subject: Re: [boost] Proposal: Extended Allocators (was Montonic Containers)
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-09 13:04:19

Hi Christopher,

My idea of a "monotonic allocator" is too strong to be halted by merely STL
;)

The idea is sound, either we can make it work with STL or I have to write
new containers. But as mentioned, I think we can still do it via allocators.
Obviously my initial implementation is not sufficient. I didnt't think it
would be; but the idea and semantics are sound, I think we just need to find
a way to make it work on all targets.

Regards,
Christian

On Wed, Jun 10, 2009 at 1:49 AM, Christopher Jefferson <
chris_at_[hidden]> wrote:

> 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
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>