Re: A constrained singleton sanity check
On 18 avr, 18:24, stevewilliams2...@comcast.net wrote:
On Apr 18, 2:10 am, James Kanze <james.ka...@gmail.com> wrote:
Do you ever actually need both 3 and 4 in the same program?
But a resurected singleton isn't the same instance as the
original singleton. If you resurected, it's not really a
Note that your code may cause multiple creations during program
start-up as well. All it guarantees is that there is never more
than one instance of a singleton alive at any given time. Which
is fine if the singleton has no variable state, but if it has no
variable state, one can argue that there's no need for it to be
a singleton in the first place.
Well, the the singleton in this program is actually behaving as a
proxy for a remote object outside the program (and eventually might be
even across a network), which does have a variable state. The purpose
of this singleton is to open the remote connection, provide the remote
interface, and cleanly close the connection when it is done. So in
fact I don't mind a few extra open/close pairs during static/global
init or during static/global cleanup - because this is only for the
brief periods of program startup and shutdown (I don't like it, but
can live with it if I am still satisfying my constraints).
OK. It's a special case. I wouldn't make it a generic
solution. (99% of the time, I don't need a destructor in my
singletons.) But if it solves a specific problem, why not?
Maybe I'm approaching the whole problem a bit wrong, it just
seemed to me the singleton was the closest to what I needed
but it ended up needed much more tweaking than I expected.
Well, it's not a singleton in the true sense, but it could be
what you need in this special case.
James Kanze (GABI Software) email:firstname.lastname@example.org
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