I've just come across the intrusive list class in the sandbox. I've been searching for a class like this for quite some time, but I never thought to look through the boost sandbox area for it. I can finally ditch my own partial implementation and use this nice alternative! 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. 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. 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. I find it interesting that under the "move sematics" C++0x proposal, the ilist could be given move sematics and thus fit into STL containers. Is there any ongoing interest in this class, and will it eventually make it into the boost proper? Geoff
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
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
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
Hi, Geoff Carlton wrote: people have finished their work on the 1.33 release. 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. 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
Olaf Krzikalla wrote:
Hi,
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?
Sorry, I was a bit confused here. A previous implementation I have seen deleted the nodes on clear(), and suffered from the problems I outlined above. I had assumed that this implementation did the same, but now I have double checked I see that instead it just unlinks the nodes and lets them go free. That makes more sense. Geoff
participants (2)
-
Geoff Carlton -
Olaf Krzikalla