Destructor for static fields. Singleton realization

Question

So, classic simple Singleton realization is following:

class Singleton
{
private:
    static Singleton* singleton;
    Singleton() {}
public:
    static Singleton* getInstance();        
};

cpp-file:

Singleton* Singleton::singleton = 0;

Singleton* Singleton::getInstance()
{
    if (!singleton)
    {
        singleton = new Singleton;
    }

    return singleton;
}

I see memory leak here - 'cos there is no delete for the new. But in C++ there isn't static destructor, so we just don't care about this memory leak?

Singletons are expected to be useful for the whole life of the program. — zneak
See C++ Singleton design pattern (or just search for singleton on SO, you will find a lot of info) — Jesse Good
This looks as rewritten Singleton implementation in C#: msdn.microsoft.com/en-us/library/ff650316.aspx But in C# "new" does not require "delete". — SChepurin
@Hate.Nothing's perfect. There is a lot to be discussed about Singleton's deletion "How does a Singleton ever get deleted?": sourcemaking.com/design_patterns/to_kill_a_singleton — SChepurin

templatetypedef templatetypedef · Accepted Answer · 2012-04-01T20:47:21

A memory leak is more than just an allocation with no matching free. It's when you have memory that could be reclaimed because the object is no longer in use, but which doesn't ever actually get freed. In fact, many memory leaks are cases where there is code in the program to deallocate memory, but for whatever reason it doesn't get called (for example, a reference cycle). There's a lot of research on how to detect these sorts of leaks; this paper is an excellent example of one such tool.

In the case of a singleton, we don't have a leak because that singleton exists throughout the program. Its lifetime is never intended to end, and so the memory not getting reclaimed isn't a problem.

That said, the code you have above is not how most people would implement a singleton. The canonical C++ implementation would be something like this:

class Singleton
{
private:
    /* No instantiation. */
    Singleton() {}

    /* Explicitly disallow copying. */ 
    Singleton(const Singleton&) = delete;
    Singleton& operator= (const Singleton&) = delete;

    /* In C++03, the above would be written as
     *
     *    Singleton(const Singleton&);
     *    Singleton& operator= (const Singleton&);
     * 
     * and you'd just leave the methods unimplemented.
     */
public:
    static Singleton& getInstance();        
};

.cpp file:

Singleton& Singleton::getInstance() {
    /* Have a static local variable representing the unique instance.  Since
     * it's static, there is only one instance of this variable.  It's also only
     * initialized when getInstance is called.
     */
    static Singleton theInstance;
    return theInstance;
}

Now there's no dynamic allocation at all - the memory is allocated by the compiler and probably resides in the code or data segment rather than in the heap. Also note that you have to explicitly disallow copying, or otherwise you could end up with many clones of the singleton.

The other advantage of this is that C++ guarantees that at program exit (assuming the program terminates normally), the destructor for theInstance will indeed fire at the end of the program. You can thus define a destructor with all the cleanup code you need.

Hope this helps!

Destructor for static fields. Singleton realization

3 Answers

Why you should avoid such code, when there is no matching `delete` for `new`

What can be done here

Destructor for static fields. Singleton realization

3 Answers

Why you should avoid such code, when there is no matching delete for new

What can be done here

Why you should avoid such code, when there is no matching `delete` for `new`