From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-08-24 19:05:43
Robert Ramey wrote:
> c) the synopsis specifies
> static unspecified instance;
> But the Expression Symatics specifies D::instance->m which seems
> inconsistent to me.
Why? 'm' is a member of the derived class. Obviously it's a user-defined
thing, so I can't specify what it is.
> I Rather expect the synopsis to say
D::instance is a pointer-like proxy. We can't overload operator., we
can't expose the object directly (to ensure initialization) and we can't
implement automatic locking if we expose the object by returning it.
Nice bonus: There seamless interoperability with anything that accepts a
> d) what about access to object which don't require thread locking - for
> const members. Do they need locking/leasing also? I would guess not but?
As explained in my previous reply 'mutexed_singleton' locks every access
(imagine you're iterating a list to get the const result - if that list
is not locked it might get modified and the program might e.g. access
freed memory) while 'singleton' puts synchronization in the
responsibility of the user. If your objects are immutable (all member
functions are const and no mutable members are present) you can just use
'singleton' and no locking is done.
> e) What does D::instance return ? a reference or pointer to the single
> instance of D
> or something else. I would expect the former, but the synopsis contains
> static "unspecified" instance
> rather than
> static T instance as I would expect.
No, it's a proxy of unspecified type.
Implementation detail: That proxy's operator-> returns T* for
'singleton' and yet another proxy for 'mutexed_singleton'.
> f) can "const" static objects be created?
I'm not sure I've tried, yet.
What would it be good for (as it doesn't make a difference if the
singleton instance is immutable and it would yield inaccessible code if
Maybe it should be possible for completeness...
> g) what happens if same interface used by different DLLS. Is one instance
> still created?
Thanks for your comments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk