What is the reason to prefer the current instance/lease formulation instead of typedef ... instance_type; instance_type instance(); // automatically serves as a lease ? (Also, why mutexed_singleton? Mutexed is not a word; synchronized_singleton maybe?) Apologies if these have already been answered. I lost track of the thread. Appalling, I know.
Peter Dimov <pdimov <at> pdimov.com> writes:
What is the reason to prefer the current instance/lease formulation instead of
typedef ... instance_type; instance_type instance(); // automatically serves as a lease
?
Exactly. No reason what so ever IMO. Author argues that his design allows automatic locking of class method invocation. But IMO this iswrong in a first place and if necessary can be achived with layered design.
(Also, why mutexed_singleton? Mutexed is not a word; synchronized_singleton maybe?)
singleton<syncronized<T> > Gennadiy
Peter Dimov wrote:
What is the reason to prefer the current instance/lease formulation instead of
typedef ... instance_type; instance_type instance(); // automatically serves as a lease
?
As we can't expose the instance when automatic locking is done, it is supposed to provide a means to not have to access the instance directly.
(Also, why mutexed_singleton? Mutexed is not a word; synchronized_singleton maybe?)
Apologies if these have already been answered.
No, they haven't. And there were no complaints about the no-word either, so far :-). Regards, Tobias
Tobias Schwinger:
Peter Dimov wrote:
What is the reason to prefer the current instance/lease formulation instead of
typedef ... instance_type; instance_type instance(); // automatically serves as a lease
?
As we can't expose the instance when automatic locking is done, it is supposed to provide a means to not have to access the instance directly.
I'm not sure what this reformulation cannot do that the original can. An ordinary singleton can define instance_type as T*. A synchronized singleton can define instance_type as the moral equivalent of shared_ptr<T> (with a hidden unlocking deleter). What am I missing?
Peter Dimov wrote:
Tobias Schwinger:
Peter Dimov wrote:
What is the reason to prefer the current instance/lease formulation instead of
typedef ... instance_type; instance_type instance(); // automatically serves as a lease
? As we can't expose the instance when automatic locking is done, it is supposed to provide a means to not have to access the instance directly.
I'm not sure what this reformulation cannot do that the original can. An ordinary singleton can define instance_type as T*. A synchronized singleton can define instance_type as the moral equivalent of shared_ptr<T> (with a hidden unlocking deleter). What am I missing?
It was one goal to enforce client code not to make any assumptions about the type of the pointer. The reason was easy migration from an unsynchronized to a synchronized scenario by enforcing threading-agnostic client code. Further, I found 'T::instance->foo()' syntacticly nicer than 'T::instance()->foo()' or 'T::instance().foo()' . Regards, Tobias
participants (3)
-
Gennadiy Rozental -
Peter Dimov -
Tobias Schwinger