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
>> 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
- 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
-- Cory Nelson
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk