Destroy a Singleton : static or not static ?

Discussion in 'C++' started by requinham, Feb 16, 2010.

  1. requinham

    requinham Guest

    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 !
    requinham, Feb 16, 2010
    #1
    1. Advertising

  2. 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 <> 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 !
    Clement Cousin, Feb 16, 2010
    #2
    1. Advertising

  3. requinham

    requinham Guest

    On 16 fév, 14:16, "Leigh Johnston" <> wrote:
    > "requinham" <> wrote in message
    >
    > news:...
    >
    > > 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
    requinham, Feb 16, 2010
    #3
  4. requinham

    John H. Guest

    On Feb 16, 7:27 am, requinham <> 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...
    John H., Feb 16, 2010
    #4
  5. requinham

    requinham Guest

    On 16 fév, 16:52, Christian Hackl <> 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
    >
    >
    > 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 !!
    requinham, Feb 16, 2010
    #5
  6. requinham

    requinham Guest

    On 16 fév, 22:18, Paavo Helde <> wrote:
    > requinham <> wrote in news:71dbb2d5-bb55-49b8-af64-
    > :
    >
    >
    >
    >
    >
    > > On 16 fév, 16:52, Christian Hackl <> 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
    > >>

    >
    > >> 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.
    requinham, Feb 16, 2010
    #6
  7. requinham

    James Kanze Guest

    On Feb 16, 1:16 pm, "Leigh Johnston" <> wrote:
    > "requinham" <> wrote in message


    > news:...


    > > 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
    James Kanze, Feb 17, 2010
    #7
  8. requinham wrote:

    > On 16 fév, 22:18, Paavo Helde <> 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
    Gerhard Fiedler, Feb 17, 2010
    #8
  9. requinham

    requinham Guest

    On 16 fév, 14:10, requinham <> 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 :D
    }
    ....
    void finalize()
    {
    A::destroy();
    /*this is a good idea because delete NULL is never a problem*/
    }

    thinks for all
    requinham, Feb 17, 2010
    #9
  10. On 18 fév, 13:07, "Leigh Johnston" <> wrote:
    > "James Kanze" <> wrote in message
    >
    > news:...
    >
    >
    >
    > > On Feb 16, 1:16 pm, "Leigh Johnston" <> wrote:
    > >> "requinham" <> wrote in message

    >
    > >>news:....

    >
    > >> > 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
    Michael Doubez, Feb 18, 2010
    #10
  11. requinham

    James Kanze Guest

    On Feb 18, 12:07 pm, "Leigh Johnston" <> wrote:
    > "James Kanze" <> wrote in message


    [...]
    > news:...
    > >> 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).


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

    --
    James Kanze
    James Kanze, Feb 18, 2010
    #11
  12. On 18 fév, 14:10, "Leigh Johnston" <> wrote:
    > > 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).

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

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

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

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

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

    --
    Michael
    Michael Doubez, Feb 19, 2010
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ook
    Replies:
    2
    Views:
    323
  2. Proton Projects - Moin

    Singleton - Whether Cloneable overrides Singleton

    Proton Projects - Moin, Mar 26, 2007, in forum: Java
    Replies:
    4
    Views:
    3,237
    Proton Projects - Moin
    Mar 27, 2007
  3. Ron Eggler

    destroy singleton?

    Ron Eggler, Apr 10, 2008, in forum: C++
    Replies:
    6
    Views:
    877
    Brian Tyler
    Apr 11, 2008
  4. Wilhelm
    Replies:
    1
    Views:
    162
  5. Trans
    Replies:
    12
    Views:
    273
    Robert Klemme
    Sep 14, 2007
Loading...

Share This Page