|
Boost : |
Subject: Re: [boost] Proposal: Monotonic Containers
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-06-10 17:28:25
On 10 Jun 2009, at 22:08, Thorsten Ottosen wrote:
> Christopher Jefferson skrev:
>
>> Very interesting. I have been working on a similar, but much more
>> limited, proposal which just does this for vector.
>> I decided I had to implement a new class, because building on top
>> of the 'allocator' framework wasn't sensible, because you waste too
>> much buffer space. For example, I believe your example won't work.
>> I'd be interested to see what you think.
>> Consider your example, in g++ (which I know how it operates
>> internally)
>> boost::monotonic::inline_storage<100*sizeof(Object)> storage; //
>> create local storage on the stack boost::monotonic::vector<Object>
>> deathrow(storage); // create a std::vector that uses this storage
>> foreach (object in world)
>> { if (IsDead(object)) deathrow.push_back(object); // allocation is
>> just advancing a pointer }
>> This will build a vector which will continuously expand, through
>> sizes 1,2,4,8,16,32. At each step, it will allocate a new block of
>> memory and free the old one, making the storage size
>> 1,3,7,15,31,63. When we try to push_back beyond 32 elements, the
>> next allocation will overflow the buffer.
>> Am I missing something?
>
> Maybe
>
> http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/
> http://www.cs.aau.dk/~nesotto/boost/trunk/boost/auto_buffer/
>
> is what you are looking for?
That doesn't do exactly what I want for two reasons, but most might be
fixable.
1) I want run-time variable amounts of space (this does involve some
alloca, and probably macro, hackery).
2) I want it to be an error if it is necessary to go to the heap.
For (1) I use a macro something like:
#define GET_ALLOCA_MEM(type, x) box<type>(x, alloca(x * sizeof(type))
Because obviously you can't call alloca inside the auto_buffer
constructor.
Chris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk