Since my last post concerning my implementation of a composite and visitor framework, I have been working on a memory management policy for the composite. The new version of the code is available in the sandbox. I would like to highlight the key changes, along with a few comments from a very useful offline discussion I had with Pavel Vozenilek: 1) A few bugs have been fixed - specifically to do with memory management. I haven't written a full test suite yet (but intend to do so in the near future) so I can't guarantee any degree of robustness in the code as yet. 2) I have put in 3 memory management policies. These enable you to ignore memory management, allow the composite to be responsible for its own memory with conventional pointers, or allow the composite to be responsible for its own memory with boost smart pointers. As yet I have been unable to sort out deep copying of the tree with the smart pointer policy. One option on this may be to implement shallow copies of the tree in the copy constuctor and equals operator, and implement a separate deep_copy function. What are the general views on this? Are there any tricks with boost shared_ptrs that enable you to do deep copies of trees from the constructor? 3) I am intending to put in a policy that will allow you to select the type of container used for internal storage. Thanks to Pavel for this suggestion. 4) I know that this is not strictly a composite in the traditional GoF sense. I actually created this particular version of a composite due to the fact that it is easier to write deep iterators when every node in a composite tree knows that it is part of the tree (unlike the GoF model where only the group nodes actually know about the tree structure). My design goals for this code were: a) Create a tree where individual nodes know about their location in the tree. b) Provide various iterators for this tree. c) Provide tight integration with the visitor pattern. These design goals were specifically designed to try and reduce virtual function bloat that, in my experience, is common with composites. In discussion with Pavel, I have come up with a design that also succeeds in meeting these criteria but ensures that leaf nodes do not carry around an empty list. I am working on this at present, but it is worthy of note that the API will be slightly more complex. The files in the sandbox are now: composite_visitor.zip - contains only the composite and visitor headers and a quick instruction document. composite_visitor_tests_win32.zip - contains the win32 test program. I haven't included the vcproj or sln files, but they should be trivial to create. Dave Handley