Pierre-Jules Tremblay wrote:
On Jan 16, 2008 3:15 AM, Tobias Schwinger <tschwinger@isonews2.com> wrote:
thank you for your review.
You are most welcome. Thank you for your response to my comments.
Thanks again. This one was an interesting read, too.
For instance, the design could be made more flexible by allowing thread-safety to be specified as a policy (with appropriate default) or by delegating the responsibility to the wrapped type. OK, FWIW policies complicate things. And what's their benefit here?
In some cases, policies do complicate things. For instance, while I have marveled at the Loki Singleton implementation, it is at one extreme of the general-purpose design spectrum and I'm not willing to pay the price (in complexity).
Yep. I did my best to avoid a Loki-style design.
The solution to the OOI problem does not scale, and I would go as far as saying that it doesn't work in practice. In my experience, it's a constant maintenance nightmare to try and keep the various slot assignments in the correct order (I have to deal with a large number of singletons; yes that is a problem in and of itself - this library will do nothing to discourage it). You must have misunderstood the docs. OOI is not done with slots. The slots are to prevent unnecessary resurrection during destruction.
Okay, I should have said "OOD" (order of destruction) instead. So reading the documentation:
Singleton instances are normally destroyed in reverse order of their construction, that is for a group of Singletons with their integral DisposalSlot template arguments being equal, where the destruction of these groups is ordered by the ascending DisposalSlot values. We could raise the DisposalSlot value of global_log from the previous examples to make sure it outlives other singletons that use 0 (the default): (...)
That, to me, sounds like the slot mecanism is for handling dependencies, in which case one must be careful in selecting which singletons fit in which slot.
Well, it's a means to override a default behavior that should just work in a majority of cases: o Reverse order of construction, and o resurrection.
Finally, this may constitute a minority opinion but I like to consider global access and single instance as orthogonal concepts. One may want to ensure a resource is only instantiated once without necessarily providing global access to that resource. So Singletons should be dynamic arrays in your opinion?
I'm not sure what you mean, and I haven't had coffee yet so perhaps that's why ;-). How do dynamic arrays help separate the concepts of preventing a second instantiation and global access to the first instance?
They allow more instances at one global access point. Regards, Tobias