Boost logo

Boost :

From: Olaf Krzikalla (krzikalla_at_[hidden])
Date: 2005-06-27 03:58:28


Geoff Carlton wrote:
> Is there any ongoing interest in this class, and will it eventually
> make it into the boost proper?
I hope it will. There was a discussion about the purpose and usage of
such a class some times ago at this mailing list - without a final
conclusion. So I just worked on (and the next iteration is coming soon),
but the formal review request will be delayed at least until the boost
people have finished their work on the 1.33 release.

> One issue I have seen with this class is that it destroys its nodes on
> list destruction. Previously implementations I have seen instead
> assert(empty()), leaving it up to the programmer to explicitly decide
> what to do. In some cases it is indeed to clear the list, but in others
> it may be to dethread the list and do something else entirely with the
> nodes.
If you detach (same as dethread? - english isn't my native language) the
list from the nodes of the elements, then the nodes either form a ring
afterwards or the nodes have some dangling pointers. IMHO in both cases
the only thing you can do with such nodes is either destruction or

> An example is in the common pattern:
> array<particle> myPool;
> ilist<particle> activeList;
> ilist<particle> freeList;
> Under this scheme the nodes were allocated in the array and then
> threaded onto their respective lists. As such, automatic deletion would
> cause a crash, and the programmer should instead just "leak" the list
> back into the array.
I don't think so. If myPool leaves its scope before the lists do, then
the node destructor of particle removes the elements of myPool
implicitly from the lists. At least there is no danger. But...

   array<particle> myPool;
   ilist<particle> activeList;
   ilist<particle> freeList;
   // do something
} // all three go out of scope at same time

... there is a severe performance penalty in my approach. In fact,
sometimes it's not necessary to waste time for unlinking list nodes,
since they are destructed anyway. Thanks for the point. I have to work
on that.

> Another disadvantage of the destructor calling clear() is that it
> prevents the node class from having a private destructor. Objects may
> need to be deleted via a manager class, however the destructor's clear()
> will cause a compile error in this situation.
This part I didn't fully understand. Can you give a little example?

Best regards
Olaf Krzikalla

Boost list run by bdawes at, gregod at, cpdaniel at, john at