Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-03 10:53:38


scleary_at_[hidden] wrote:

> If you look at my implementation, the link to the next block actually points
> to the next block's link to *it's* next block (i.e., it points into the
> footer of the next block). So you can work backwards from the "next block's
> link to it's next block" into the "next block's pointer for it's shape
> descriptor", and get the size of the next block from that. Twisted, but it
> should work :)

        I take back my previous comments: what you do works because
all the blocks are the same size (and your solution is conforming
because
the user nominates the size: a block of size n aligned n is always
suitable for allocating any object of length n or less)
 
> This will *not* work, though, if you ever wanted to allow the user to
> deallocate a block (since, as you pointed out, you can't find the footer
> without an expensive list search).

        I don't currently allow that. However:

        1. I plan to allow user deletion
        2. I plan to provide reference counting as well
        3. I currently use malloc/free for allocation,
                although I plan to extend that to an
                arbitrary allocator.

All three of these points prevent the footer being at the end.
In particular, an arbitrary allocator won't allocate store
contiguously, so your trick -- which amounts to the footer
of one block being at the head of another <very cute!> won't work
for me.

        The problem would go away if I required all collectable
objects be derived from some base. That onerous and totally
ugly requirement is deliberately avoided. :-)

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk