Re: Confused about a thread-safe singleton example.
On Dec 5, 4:27 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
On Dec 5, 9:07 am, James Kanze <james.ka...@gmail.com> wrote:
On Dec 4, 4:58 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
[]
So, a global variable can be an instance of a singleton class,
can it not?
It would depend on how the singleton is implemented. The
oldest, traditional implementation (use a static counter,
incremented in the constructor, and assert that it is never
greater than 1 after the incrementation) certainly allows
it. Most of the C++ implementations wouldn't allow it,
requiring you to go through a special function. More
generally, I think, this is usually the case in other
languages as well, since by making the constructor private,
and requiring the function to be called, makes it impossible
to write compilable code which would instantiate more than
one instance.
It's not a perfect solution, however---as I think you
mentionned, it doesn't allow derivation, at least not easily.
It was mentioned by Alan Johnson.
Personally, I prefer deriving from interface classes only, for
anything else composition seems to me to be a superior
approach, so whether something can be derived from is the last
thing I would care.
You prefer deriving.../whether something can be derived from is
the last thing you care. Seems like a contradiction.
There are clearly times when deriving from something that isn't
a pure interface is justified -- the template method pattern, or
mixins, for example -- although it's probably overused. But
that begs the question: there's no real reason why a singleton
shouldn't be a pure interface, in the classical sense of the
word. In the Unix world, for example, it's usual to have a
singleton factory class for the creation of GUI components. All
the user sees is an interface, however, since there are
different derived classes according to which look and feel is
wanted (Motif, Athena, etc.). Which derived instance is present
is determined at runtime (usually by controlled dynamic
linking), but there can be at most only one of them.
And all those calls to instance() ARE a real pain in the neck.
The problem, IMO, is that it is supposed to limit the number
of instances on the type level. Yet, there is a price to be
paid at run- time for every usage of ::instance() call (albeit
small). On the other hand, accessing good old global variables
(or global references to abstract interfaces) has zero price
and seem to work quite well when I need one instance of
something and it does not require special syntax for accessing
that instance (less typing at the least).
It's not so much the runtime cost which bothers me, as the
clutter in the source files. Increased typing time, and also
increased reading time, and time necessary to find what you're
looking for. When it comes down to it, the function call is
noice.
I have my one instance and I just can't be bothered to enforce
that by making the class a singleton, for the very same reason
that I can't be bothered to prohibit derivation from classes
that are not supposed to be derived. If someone wants to shoot
his foot off I won't mess with the person's good will,
experience work best when it is obtained first hand ;).
The problem in this case is that you're not alone. So you have
to coordinate who defines the unique instance, etc. It creates
a (small) management problem.
And there is, of course, the order of initialization issue.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34