Destroy a Singleton : static or not static ?

R

requinham

Hello,

i would know if the conception of singeleton pattern define the
function who destroy the unique instance as static or not ?

because in the code of global program, this function must be the
latest function executed by the singleton and after that she will
return the handle to the main or another independant function so it's
not necessary to define this method (destroy()) as static !
 
C

Clement Cousin

You should have a look at the atexit function.
Imho, you should use a failsafe, generic Singleton implentation such
as the one in the A.Alexandrescu's Loki library instead of writing
your own (and btw have a look at the sources to understand how it
behaves)
 
R

requinham

Could you be more specific as there are various ways of implementing a
singleton.  If you are using the Meyers Singleton then there is no need for
a destroy function static or otherwise as the singleton is destroyed
automatically at the appropriate time during program termination.

/Leigh

thinks for all for this qwickly response :)

for the implementation, i use a simple and classic method like this :

class A {

private:
A(){};
A(const A& instance){};
~A(){};
static A* uniqueInstance=NULL;

public:
static A* getInstance(){
if (uniqueInstance==NULL)
uniqueInstance=new A();
return uniqueInstance;
}

void destroy(){
if (uniqueInstance != NULL){
delete uniqueInstance;
uniqueInstance=NULL;
}

}

is like this and normally in all the case, the destroy function is
called at the end of singleton then it's not important to make it
static
 
J

John H.

class A {

private:
A(){};
A(const A& instance){};
~A(){};
static A* uniqueInstance=NULL;

public:
static A* getInstance(){
if (uniqueInstance==NULL)
   uniqueInstance=new A();
return uniqueInstance;

}

void destroy(){
if (uniqueInstance != NULL){
delete uniqueInstance;
uniqueInstance=NULL;

}
}

is like this and normally in all the case, the destroy function is
called at the end of singleton then it's not important to make it
static

In this case I would say you want to make it static.
If the method doesn't use any non-static members, then the method
itself can be static. A rough rule of thumb, if you can make it
static, go ahead and do so. The advantage is that you can call the
function without needing an instance, e.g. you can call A::destroy()
instead of A::getInstance()->destroy().
In your case, you are probably right in that it doesn't make much
difference either way.
As a silly aside, if destroy() is non-static, then while calling
A::getInstance()->destroy(), there is brief moment where you are
executing the method of an object that has been destroyed. It seems
disturbing...
 
R

requinham

requinham ha scritto:


Normally, you should not destroy the instance at all. Why would you want
to destroy it before the program ends?

--
Christian Hackl
(e-mail address removed)

Milano2008/2009begin_of_the_skype_highlighting              2008/2009      end_of_the_skype_highlighting-- L'Italia chiamò, sì!

for the reason of destroying the singleton, i would like to give an
example :
if i have an GUI application with several features including one who
call a DLL library for parsing a file and mapping her content in
several struct. After that the others functionality uses those struct
for accomplish her job.
in the case where i would change the input file without closing my
GUI, i should destroy the singleton (firstly created by the DLL).

this is an example. in fact my question concern the conception level,
the calling of destroy function from the singleton A::getInstance()-
destroy() is without problem because it's the last instruction in the
execution life of the singleton and if we supposed that destroy
function is static, we don't found the reason for calling it without
having an instance in the memory, so it doesn't have a sens. So in my
opinion the function destroy() should not be static !!
 
R

requinham

(e-mail address removed):






Then this is not a singleton. Imagine your GUI will be enhanced to
incorporate tabbed windows, each displaying its own file.


For a non-singleton, naturally the destroy() function cannot be static.

Singletons are used for managing very specific resources common to the
whole application, like a custom memory pool or something. If you feel
you need to destroy the singleton in the middle of the program, then this
is a strong hint the singleton idiom is not a correct one.

Paavo

Why this is not correct ? the idiom of singleton is not in conflict
with destroying it in the middle of the program and we could find
several example of this way in the web.
 
J

James Kanze

Could you be more specific as there are various ways of
implementing a singleton. If you are using the Meyers
Singleton then there is no need for a destroy function static
or otherwise as the singleton is destroyed automatically at
the appropriate time during program termination.

For some definition of "appropriate". Generally, it's
preferrable that a singleton never be destroyed.
 
G

Gerhard Fiedler

requinham said:
Why this is not correct ? the idiom of singleton is not in conflict
with destroying it in the middle of the program and we could find
several example of this way in the web.

If your singleton is managing one of several files, and the file that it
is managing may change, you can't really create a singleton with the
code you showed earlier -- the ctor would need the file path, wouldn't
it?

You of course could have a singleton, and use a load() function of it to
load a given file (and, if you need it, an unload() function to unload
it). But as Paavo says, what is then really singleton about this class?
It's a class that manages access to several files, typically with one
instance per file rather than one instance per process.

A singleton is generally a class that has, by its very nature, only one
instance per process, without configuration by the user and without
lifetime management (other than instantiating it on first use). Yours
doesn't seem to fit into this definition (which of course is not the
only one).

I'm positive that it is possible to implement pretty much anything with
the singleton idiom, and that some of this has been done. This doesn't
say much, other than that C++ is a flexible gun that allows you to shoot
yourself into the foot while aiming at the horizon :)

Gerhard
 
R

requinham

Hello,

i would know if the conception of singeleton pattern define the
function who destroy the unique instance as static or not ?

because in the code of global program, this function must be the
latest function executed by the singleton and after that she will
return the handle to the main or another independant function so it's
not necessary to define this method (destroy()) as static !

Finally i found the reason for which the destroy function, if exist,
must be static.
in fact, the reason is simple: if the member function destroy was not
static, it depends ... an instance of your singleton.

However, it is perfectly possible that you want to use (creating if
necessary) your singleton instance of "everywhere" and you want to
destroy it in only one location (typically, during the "off" end)
while ... you do not have necessarily a pointer to the singleton
instance of your ... example :

void finalize()
{
A::getInstance()->destroy();
/*this is not a good idea*/
}
but
....
static A::destroy()
{
delete uniqueInstance; // pas besoin de test
uniqueInstance = NULL; // tant pis si uniqueInstance vallait déjà
NULL
// maintenant, on en est sur :D
}
....
void finalize()
{
A::destroy();
/*this is a good idea because delete NULL is never a problem*/
}

thinks for all
 
M

Michael Doubez

Garbage.  It is preferable that a singleton is destroyed in a deterministic
order relative to other static duration objects during program termination
and this happens automatically and is defined by the language (when using
Meyers Singleton).

But the standard doesn't address multithreading. The Meyer singleton
may be a problem when a thread still needs the singleton that the main
thread has already destroyed (upon ::exit(0) by example).
 Alexandrescu advocates a phoenix singleton which can be
destroyed and recreated but I dislike this.

The phoenix singleton has the advantage of handling the case I
mentionned and it may happen that a singleton destruction requires
another already-destructed singleton (like a singleton destroying
registered objects that log the event).

As James Kanze, for some definition of "appropriate", it is best to
let the garbage collector do this work.
 
J

James Kanze

"James Kanze" <[email protected]> wrote in message

[...]
Garbage. It is preferable that a singleton is destroyed in a
deterministic order relative to other static duration objects
during program termination and this happens automatically and
is defined by the language (when using Meyers Singleton).

Only if you like undefined behavoir, or can guarantee that the
singleton won't been accessed from the destructors of any static
objects. Destructing the singleton sort of defeats its purpose.
Alexandrescu advocates a phoenix singleton which can be
destroyed and recreated but I dislike this.

Me too. It's not really a singleton (but it can work as one in
many cases).
 
M

Michael Doubez

Threading issues are a problem yes but it is poor quality software that has
threads other than the main thread still running when exiting main().

Or a good software using poor quality library.
Phoenix singleton does not solve the problem of singletons (or global
variables) being problematic in multi-threaded designs.  The goal should be
to minimize shared state when using multiple threads and singletons (or
global variables) are an anathema to this.

Yes, it should.
What garbage collector?  I am talking about the language guarantee that
static duration objects are destroyed in reverse order of their creation.

I am talking about OS' garbage collector reclaiming dynamically
allocated objects ; they are not really destroyed but cease to exists.
That doesn't solve singleton managing OS wide resources such as shared
memory but those are special case where a Meyer singleton can be
applied.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

destroy singleton? 6
Static if 2
static class member initialization 1
DESTROY gotcha 5
A constrained singleton sanity check 3
Singleton vs static 11
Instance() in Singleton Class Question 2
static members 8

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top