Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Destroy a Singleton : static or not static ?

Reply
Thread Tools

Destroy a Singleton : static or not static ?

 
 
requinham
Guest
Posts: n/a
 
      02-16-2010
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 !
 
Reply With Quote
 
 
 
 
Clement Cousin
Guest
Posts: n/a
 
      02-16-2010
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)


On Feb 16, 2:10*pm, requinham <(E-Mail Removed)> wrote:
> 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 !


 
Reply With Quote
 
 
 
 
requinham
Guest
Posts: n/a
 
      02-16-2010
On 16 fév, 14:16, "Leigh Johnston" <(E-Mail Removed)> wrote:
> "requinham" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> > 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 !

>
> 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
 
Reply With Quote
 
John H.
Guest
Posts: n/a
 
      02-16-2010
On Feb 16, 7:27*am, requinham <(E-Mail Removed)> wrote:
> 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...
 
Reply With Quote
 
requinham
Guest
Posts: n/a
 
      02-16-2010
On 16 fév, 16:52, Christian Hackl <(E-Mail Removed)> wrote:
> requinham ha scritto:
>
> > i would know if the conception of singeleton pattern define the
> > function who destroy the unique instance as static or not ?

>
> Normally, you should not destroy the instance at all. Why would you want
> to destroy it before the program ends?
>
> --
> Christian Hackl
> (E-Mail 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 !!
 
Reply With Quote
 
requinham
Guest
Posts: n/a
 
      02-16-2010
On 16 fév, 22:18, Paavo Helde <(E-Mail Removed)> wrote:
> requinham <(E-Mail Removed)> wrote in news:71dbb2d5-bb55-49b8-af64-
> (E-Mail Removed):
>
>
>
>
>
> > On 16 fév, 16:52, Christian Hackl <(E-Mail Removed)> wrote:
> >> requinham ha scritto:

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

>
> >> Normally, you should not destroy the instance at all. Why would you

> want
> >> to destroy it before the program ends?

>
> >> --
> >> Christian Hackl
> >> (E-Mail 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).

>
> Then this is not a singleton. Imagine your GUI will be enhanced to
> incorporate tabbed windows, each displaying its own file.
>
> > 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 !!

>
> 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.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-17-2010
On Feb 16, 1:16 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
> "requinham" <(E-Mail Removed)> wrote in message


> news:(E-Mail Removed)...


> > 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 !


> 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.

--
James Kanze
 
Reply With Quote
 
Gerhard Fiedler
Guest
Posts: n/a
 
      02-17-2010
requinham wrote:

> On 16 fév, 22:18, Paavo Helde <(E-Mail Removed)> wrote:
>> 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.

>
> 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
 
Reply With Quote
 
requinham
Guest
Posts: n/a
 
      02-17-2010
On 16 fév, 14:10, requinham <(E-Mail Removed)> wrote:
> 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
}
....
void finalize()
{
A::destroy();
/*this is a good idea because delete NULL is never a problem*/
}

thinks for all
 
Reply With Quote
 
Michael Doubez
Guest
Posts: n/a
 
      02-18-2010
On 18 fév, 13:07, "Leigh Johnston" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
>
>
> > On Feb 16, 1:16 pm, "Leigh Johnston" <(E-Mail Removed)> wrote:
> >> "requinham" <(E-Mail Removed)> wrote in message

>
> >>news:(E-Mail Removed)....

>
> >> > 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 !

>
> >> 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.

>
> 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.

--
Michael
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
destroy singleton? Ron Eggler C++ 6 04-11-2008 12:48 PM
Singleton Modules rather than Singleton Classes Trans Ruby 12 09-14-2007 06:45 AM
Singleton - Whether Cloneable overrides Singleton Proton Projects - Moin Java 4 03-27-2007 02:59 AM
Singleton classes and Singleton pattern Wilhelm Ruby 1 10-11-2006 01:08 PM
When to destroy, when not to destroy Ook C++ 2 10-11-2005 02:11 AM



Advertisments