Jason Hise wrote:
I have no familiarity with these patterns, so my range of suggestions is fairly limited. However, I did notice one way that you might be able to make the composite more generic. Your composite library currently forces the client to set up the hierarchy with raw pointers. Would it be reasonable to ask that it allow smart pointers as well? It would seem that this would be as easy as making the template parameter the pointer type instead of the object type, as the plain object type doesn't (appear to) be used anywhere.
Thanks for the suggestion - I've actually been working on this, along with some other memory management policies. The smart pointer policy is relatively simple, although not quite as easy as making the template parameter a pointer type since I use new, delete and clone in the framework. Nevertheless, I should be able to get that policy up and running pretty quickly. I was also trying to create a further policy that used a single type and stored it by value rather than by pointer (like normal STL containers) - unfortunately, the policy for that is proving much harder than I originally thought. I'l probably abandon my second idea and just publish policies for smart_ptr and normal pointer versions of the code.
(btw, have you tried out my singleton longevity lifetime policy yet? ;) )
I've browsed the code, but unfortuantely, I've spent a week away on business so haven't had a time to use it in anger yet, or study the code in any detail. My first impression is that you have done a good job - but I'll get back later in the week with a more detailed review. Dave Handley