Re: [boost] [allocators] Article and library about allocator improvements

From: Cory Nelson (phrosty_at_[hidden])
Date: 2008-06-24 02:35:13

On Mon, Jun 23, 2008 at 9:35 AM, Ion Gaztañaga <igaztanaga_at_[hidden]> wrote:
> Cory Nelson wrote:
>>
>> Looks very nice!  I have some code that could make good use of this -
>> I'll be playing around with it for the next few days to see how it
>> goes.
>
> Thanks!
>
>> One thing I'd be interested in is a zero-overhead scoped arena.
>> Sometimes you just need a read-only collection, and don't want a
>> pointer to a common arena (the overhead) being stored in all the
>> dynamically sized objects.  I've been using Intrusive for this
>> purpose, but it doesn't call destructors on its own and there's no
>> vector that lets you one-time sizing.
>
> I don't fully understand what you mean. Are you talking about an allocator
> that just allocates some big chunks of memory and increases a pointer to
> allocate memory (deallocation is no-op)? Could you elaborate a bit more?
>

Say you have a large structure that you only need to build once, and
won't modify after that except to delete it.  Ideally:

-  One arena (what you described) could service all the objects in the
entire structure.  This gives you high locality and no bookkeeping
overhead.

-  The objects wouldn't hold an allocator (reference to the arena).
They only need to be built once, so keeping a reference around for
future allocations is needless overhead.

-  The arena would not be in global/static storage.

-  The objects would all still have their destructors called.

This is impossible with std:: containers.  I've been using C strings,
wrappers around intrusive (to call destructors), and a tr1::array-ish
class that lets me set pointer & size.

A lot of the time the overhead of std:: containers is acceptable for
the convenience they give, but in my situation (Windows Mobile, need
to be very tight on usage) it isn't.

I think the problem is fairly common and even desktop apps would
benefit from such a design IF it where made convenient.  I admit, I
can't think of a convenient way to do this (though intrusive comes
quite close).

-- 
Cory Nelson