Re: Singleton_pattern and Thread Safety
On Dec 14, 11:44 =AC=E2=80 am, Leigh Johnston <le...@i42.co.uk> wrote:
On 14/12/2010 16:13, Leigh Johnston wrote:
Meyers Singletons do not require any explicit dependency code at the
site of their definition. The dependency is made explicit at the call
site instead (for example from user defined constructors).
I meant to say:
"Meyers Singletons do not require any explicit dependency code at the
site of their definition. The dependency *can be made* explicit at the
call site instead (for example from user defined constructors)."
I am also thinking along the lines of:
singleton_a::singleton_a() { third_party(this); }
singleton_b::singleton_b() { third_party(this); }
and you want the following two programs to behave differently:
int main()
{
=AC=E2=80 =AC=E2=80 =AC=E2=80 =AC=E2=80 singleton=
_a::instance();
=AC=E2=80 =AC=E2=80 =AC=E2=80 =AC=E2=80 singleton=
_b::instance();
}
int main()
{
=AC=E2=80 =AC=E2=80 =AC=E2=80 =AC=E2=80 singleton=
_b::instance();
=AC=E2=80 =AC=E2=80 =AC=E2=80 =AC=E2=80 singleton=
_a::instance();
}
This is true. Calling ::instance during the dynamic initialization
phase (Kanze's assignment to a file/namescape scope variable) does
prevent such customization of construction order after said phase
such as in main. That and the forced instantiation are both strong
criticisms in my opinion, especially for libraries.
The construction order of Kanze's method (assuming we introduce
dependencies between all the singletons) does not provide this
flexibility. =AC=E2=80 I have to admit that this is probably a rare
use-case though.
Except that once dependencies between the singletons (assuming you
mean in constructors as we've discussed) are in place, one cannot
circumvent the partial ordering (dependency ordering) whether they
are Meyer's or not.
KHD