Jeff Garland wrote:
Well, my feedback is going to be fairly shallow since I don't have lots of time to look it over, but what I see looks pretty good. Both of the composite and visitor stuff would be nice additions.
Thanks :-)
One interesting question on composite is whether a boost::tree would really be all that's needed and might be a more general component that could be used to implement composite. Of course, you are really depending on pointer semantics and the clone, so it wouldn't be a minor change of course to go down that path...
I'm pretty sure that the implementation I have of the composite would also work as a tree if you didn't use CRTP. I've not tested this, but just browsing my own code convinces me of it! I personally think that improvements could be made to the composite by incorporating some policies. I've not given this much thought, but options could include a memory management policy that allowed you to choose between: the current model with pointers and clone; a single type in the tree that used copy and value semantics; a smart_ptr based model.
I think instead of trying to create a 'patterns' library I would make 2 standalone libraries: vistor and composite. The fact that these are 'patterns' (ie: well known designs) isn't really strong enough to bind them together.
My reason for wanting to create a patterns library is actually from a desire to try and create a Loki equivalent in boost (with some additions). The inter-play between certain patterns is such that I think they could sit in the same library. For example, the work I've done on visiting composite trees, or the fact that an abstract factory is often a singleton, etc. Having said that, I would not be averse to them being different libraries if that was preferred. Dave