[boost] Composites and Visitors

From: Dave Handley (dave_at_[hidden])
Date: 2005-01-29 20:39:16

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