On Mon, Jun 23, 2008 at 9:35 AM, Ion Gaztañaga <igaztanaga@gmail.com> 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