Subject: Re: [boost] Proposal: Monotonic Containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-13 19:01:17
Christian Schladetsch wrote:
>> But its still not an allocation, it
>> is a re-interpretation of space within an already-allocated buffer.
> Which is what an allocation is.
> An allocation, as the name suggests, is simply the act of assigning some
> range of the computer memory to some use.
Yes, I was completely wrong about that.
Although indeed the entire buffer is first allocated, there are many
`allocations` made by different containers of different types within that
initial buffer, each requiring correct alignment.
I have corrected the deficit of the lack of corrent alignment in the code in
the sandbox. This now uses boost::aligned_storage<T> in the allocator, which
passes that down to the storage to make correctly aligned allocations within
that shared buffer.
> What you're doing is simply allocating some range of memory on the
> execution stack to your container.
That is indeed part of it, yes. Except that the same range of memory can be
used by multiple containers, the range of memory can be placed on the stack
*or* the heap, and by making de-allocation a no-op, memory management is
optimally efficient in time but always increases in space.
> I fail to see how the standard allocator concept wouldn't be as good for
It is indeed; the allocator in the proposed library is-a std::allocator. One
key extra component that the library provides is a coupling with a storage
concept that can be on the heap or the stack, and can be shared by multiple
allocators, and by being 'monotonic', memory management is extremely fast.
> Sure, the standard allocator concept has deficiencies, it doesn't provide
> two-way growing and shrinking, nor does it say how much memory it actually
> has allocated you.
> But people are working on fixing that it seems.
This proposal is not about extending or changing the std::allocator concept.
There are other systems proposed for that, as I think most agree that it
needs some work.
This proposal uses std::allocators and a common storage concept to provide
correctly-aligned allocation of objects of different types from the same
buffer which can be on the heap or on the stack, using an optimal-in-time
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk