From: Konstantin L. <to....@gm...> - 2009-10-26 14:02:40
|
On 26.10.2009 15:20, S Roderick wrote: >> If usage pattern do not involve static module initialization logic than >> proposed extension will allow users to have their own specific Category >> objects. > > That is one option. Another option might be > > static HierarchyMaintainer* _defaultMaintainer=0; > > HierarchyMaintainer& HierarchyMaintainer::getDefaultMaintainer() { > static HierarchyMaintainer defaultMaintainer; > > // use default maintainer if it is not already set > if (! _defaultMaintainer) > _defaultMaintainer = & defaultMaintainer; > > return *_defaultMaintainer; > } > > void HierarchyMaintainer::setDefaultMaintainer(HierarchyMaintainer* d) { > _defaultMaintainer = d; > } > > This allows the application to override the default maintainer > programmatically. This way is actually the same as I propose except its for HierarchyMaintainer. And no, you can't solve my problem in any other way except directly specify what exactly category object you need. There is no way to install some function that will be invoked before any static object initialization to initialize _defaultMaintainer. And I think you don't need to replace HierarchyMaintainer. You only need to add ability to create you Category objects on requests and this can be accomplished in the way I wrote in previous post. |