Hi Mathias, 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 that.
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 allocation scheme. Thanks, Christian.