Releasing attributes' memory of singleton class

Question

Considering the following Singleton class, I am not releasing memory in the destructor. But the instance of this class will remain the life-time of the program as most of the single-ton class do. Is it really matter to release the attribute's memory other than best practices perception?

class Singleton
{
private:
    Singleton() { pbyte1 = new BYTE[100]; }
    ~Singleton() {};
    BYTE* pbyte1;
    static SingletonInstance* pInstance;

    public:

    static Singleton* GetInstance()
    {
        if( pInstace ) return pInstance; 
        else 
        pInstance = new Singleton();
    }
};

Why the emphasis on the "T" - it's a singleton - one word.. :) — Nim, Sep 06 '11 at 09:38
See this: http://stackoverflow.com/questions/6993400/managing-a-singleton-destructor/6993501#6993501 — Nim, Sep 06 '11 at 09:39
Sounds like quite a heavy class. I prefer the single-cwt class personally - it's a bit lighter. — Chris J, Sep 06 '11 at 09:42
@sarat: What do you mean by "best practices"? If it's the *best* practice, do it. There's nothing better than it, by definition. — R. Martinho Fernandes, Sep 06 '11 at 09:42
The best practice is not to use singletons at all. It is just a hidden global variable anyway — BЈовић, Sep 06 '11 at 09:58
Thanks @nim. I updated. Anyway this isn't a real-world class. I was just giving out a sample. — sarat, Sep 06 '11 at 10:46

score 3 · Accepted Answer · answered Sep 06 '11 at 09:41

3

It does matter for debugging. If you run a tool for detecting memory leaks, the leaks caused by this singleton will pollute the output, making it harder to detect real memory leaks.

answered Sep 06 '11 at 09:41

Björn Pollex

75,346
28
201
283

Excellent! you got it right. It's the same story here. Because some people have already did it in this way and the tool gives hell lot of warnings :) You mean to say, I should release the resources? – sarat Sep 06 '11 at 10:44

score 3 · Answer 2 · answered Sep 06 '11 at 10:32

It depends on the nature of the resources. Usually, the best practice is not to destruct the singleton; destructing the singleton can give rise to order of destructor problems. The exception is if the singleton uses resources which won't be freed by the system (e.g. temporary files); in this case, the "classical" implementation of the instance() function is:

Singleton& Singleton::instance()
{
    static Singleton theOneAndOnly;
    return theOneAndOnly;
}

In this case, the destructor of theOneAndOnly will be called during shutdown. For this reason, you must ensure that the singleton is never used in the destructor of a static variable.

By the way, you're implementation is broken as well. It should be:

Singleton& Singleton::instance()
{
    static Singleton* theOneAndOnly = new Singleton;
    return *theOneAndOnly;
}

This is the usual solution.

Can't say it's broken. Some people prefer to use pointers rather than references. — sarat, Sep 06 '11 at 10:42
@sarat It's not a question of pointers or references (although returning a pointer means that the caller has to check for a possible null pointer). The code in the function is broken. — James Kanze, Sep 06 '11 at 12:25

score 2 · Answer 3 · answered Sep 06 '11 at 09:50

As Björn said: it matters for debugging.

It matters also for maintenance. The program will change. It will be refactored. If during refactoring a singleton suddenly isn't a singleton anymore, the missing destructor might introduce real leaks. Additionally, in the future the object might need more than memory (e.g. db handles). Not returning them on closing the program is a true error.

So if you want a best practice: Every destructor should return the resources the object owns. This includes destructors of objects where you could rely on the OS to take them on program shutdown.

score 0 · Answer 4 · answered Sep 06 '11 at 09:42

0

If the singleton instance is remaining for the lifetime, then no need to worry about releasing the class resources. When the program terminates, they will vanish (I don't mean automatic delete).

The best practice is to declare the class objects as automatic when the size is fixed.

class SingleTon
{
//...
  BYTE pbyte1[100];
//...
};

answered Sep 06 '11 at 09:42

iammilind

68,093
33
169
336

3

"then no need to worry about releasing the class resources" <- Really? There are resources other than memory. Yes, they will all "vanish", but sometimes you want them released, not "vanished". – R. Martinho Fernandes Sep 06 '11 at 09:45
@R. Martinho, I know that ideally we should release all the resources. But in this case how/when should we release the member resources of the `class SingleTon`; OP is expecting to retain the pointer `SingleTon*` for the lifetime of the program. – iammilind Sep 06 '11 at 09:55
1

Yes, that is one of the many problems a singleton introduces. Why the OP wanted to introduce this problem is beyond my knowledge, though. – R. Martinho Fernandes Sep 06 '11 at 10:00

Releasing attributes' memory of singleton class

4 Answers4