Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2001-05-03 12:02:10


> > 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)

Just for clarification: my reference to "my implementation", above, is
referring to the code I posted 2 messages ago, not the implementation of
Pool.

> 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.

Reference counting could probably be accounted for in the header/footer
info, and arbitrary allocators can be used if you put alignment restrictions
on them (as I do in Pool's UserAllocator). The first point (allowing user
deletion) is more tricky; there is one possibility, though:
  I'm assuming that you have a special pointer type (or reference-counting
pointer type) that acts as a pointer to objects that will be garbage
collected (after all special pointers pointing to them are deleted). That
special pointer type can be returned by your allocation function, and this
type could keep a pointer to the block *and* a pointer to its footer. Then
this special pointer type must be passed to your deallocation routine as
well. However, this change doesn't allow your client code to use raw
pointers to garbage-collected objects.

I don't know what exactly you're trying to do with your library, so I can't
say if this change is feasable or not; it's just a thought...

        -Steve


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