Re: [boost] intrusive list

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

Hi,

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

> 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