4
votes

Assuming this implementation of a singleton pattern ( of course we should avoid Singleton: it is just question), I have just been thinking about static object being created. It is created on heap by a new operator, sure, but how is this destroyed? In following example we have a leak, so how one should implement deletion of static singleton object? Should there be a please_delete() public interface adopted, so one can call myC->please_delete() or is there other way to achieve this?

class CC{
public:
    static CC* cObj(){
        if(c_ptr==NULL){
            c_ptr=new CC();
            return c_ptr;
        }else return c_ptr;
    }
    int getValue(){return value_;}
    void setValue(int val){value_=val;}
    ~CC(){cout<<"~CC";}
private:
    CC():value_(12345){cout<<"CC";}
    static CC* c_ptr;
    int value_;
};
// Allocating and initializing CC's
// static data member.  The pointer is being
// allocated - not the object itself.
CC *CC::c_ptr = 0;

int main(){
    //Singleton pattern
    CC* myC = CC::cObj();
    cout<<myC->getValue();
    return 0;
}

output: CC12345

RUN SUCCESSFUL (total time: 67ms)

I noticed that indeed we can always declare singleton static instance within shared_ptr as with boost::shared_ptr<CC> bCptr(CC::cObj()); but Singleton pattern doesn't mention the problem of deletion of the object at all so maybe there exists some other approach?

3
Who does singletons like this? Why not just return a static CC?Pubby
I seem to be missing the line where c_ptr is assigned a CC objecctArun
yes, sure, changed, thanks4pie0

3 Answers

8
votes

Part of the Singleton design pattern is that it is indestructible.

EDIT:

There are 2 varieties of singletons with respect to destructibility:

  1. Destructible (They die when the application does)
  2. Indestructible (They die when the machine does)

Either way, if built properly, once the singleton instance is created, it stays. This one of the major criticisms of the Singleton design pattern.

Here are a few references that address the destructibility aspect of the pattern.

http://nicolabonelli.wordpress.com/2009/06/04/singleton-a-mirage-of-perfection/ http://www10.informatik.uni-erlangen.de/Teaching/Courses/SS2009/CPP/altmann.pdf http://sourcemaking.com/design_patterns/singleton http://sourcemaking.com/design_patterns/to_kill_a_singleton

4
votes

The classical singleton pattern does not describe the deletion aspect.

However, if I have to do it, I would start with a simple approach like the following (it is not fool-proof):

1) Similar to the static method for creating/retrieving the singleton object, say createObject(), there is a static method for destructing the singleton object, say destructObject()

2) There is a counter which counts the current number of objects in the system;

  • it starts at 0
  • on createObject() call, it increments by 1
  • on deleteObject() call, it decrements by 1.
    • If it reaches 0, then the delete is called to actually destruct the object
3
votes

I prefer to not use a pointer.

class Single
{
private:
   Single();

public:
   Single& Instance()
   {
      static Single the_instance;
      Return the_instance;
   }
};

This singleton will live from the time Instance() is called until the application is exiting and performing the destruction of static objects. In this case the destructor of the singleton object will be called.

In practice, even when using a pointer as in the original example, the memory will be reclaimed by the OS upon application exit. However in this case the object's destructor will not be called.