One more Interview question

[karthick88]

in singleton class how will delete the obj ?

I don understand the question at all..

[RedX]

You could provide a function that deletes the singleton when you need it

void Class::deleteSingleton(){
  delete singleton;
  singleton = NULL;
}

or as with any other program, when the program finishes, the OS will release all the memory in use by that program. You must beware tho, if you created the singleton with "new", "delete" won't be called and so the destructor (~Class()) won't be called.

[jsmith]

Typically you wouldn't give the user the ability to destroy the singleton; it's not a singleton then.
Rather, the object should be destroyed at program exit when global destructors are run, provided
that, as RedX says, you don't dynamically allocate it. The pattern is:

MyType& GetInstance() {
    static MyType singleton;
    return singleton;
}

This will guarantee that the destructor runs when the program exits.

[karthick88]

I have a question here.. The static members usually have the scope of program rite? I.e Only when the final execution ends.. So does it matter if we don deallocate the memory??

[everid]

I have a question here.. The static members usually have the scope of program rite? I.e Only when the final execution ends.. So does it matter if we don deallocate the memory??

in case of singleton where static is used, you don't have the right to deallocate the memory. OS will take care of it for you.

[karthick88]

Oh really??? Thats great... When will the OS deallocate memory for the static objects??? In that case again, will the distructor be called??

[Zhuge]

I would say when the program ends, and yes.

[karthick88]

@Zhuge.. Great.. in that case, if the class has pointers and if memory leak happens, do we really need to bother since the memory allocation accors for the objects in the heap and anyway that memory is going to get destroyed once the process ends and in our case, even if the static object leaks memory, its going to leak at the end of the process , i.e Just before the virtual memory is about to get destroyed...!!

[helios]

and anyway that memory is going to get destroyed once the process ends

That's only generally true. An OS could exist that leaves memory management entirely up to the process. And anyway, just because the OS is going to clean up after you, it's not an excuse to be sloppy.

[Zhuge]

++helios

[Athar]

Properly cleaning up huge and/or complex data structures can sometimes take quite a while - therefore it's better not to delete the singleton when the program exits - provided it doesn't hold resources other than memory (files, mutexes, etc.) or performs other critical actions on destruction.
There are already enough programs that sit there several seconds or sometimes far longer before actually exiting after being told to do so - make sure yours is not one of them, one way or another.

...that's still not an excuse to be sloppy.

Edit: of course you're not supposed to say that in the interview, unless you can properly explain the reasons for such a decision yourself.

[helios]

http://encyclopediadramatica.com/Copypasta/Archive_4#Forgot_to_Wipe

[Disch]

There are already enough programs that sit there several seconds or sometimes far longer before actually exiting after being told to do so - make sure yours is not one of them, one way or another.

Why would the OS be able to free those resources any faster than the shutdown process of your program?

Even if you don't clean up the mess yourself, the OS still has to do all the same work of cleaning up, right?

[jsmith]

The OS knows what pages of memory it gave to a process, but it knows nothing about the contents.

The program knows that the contents are a linked list. The program therefore deletes all nodes in
the list, giving the memory back to the C++ memory manager (ie, malloc). The memory is _not_
given back to the kernel at this time.

The OS just marks all the pages of memory used by the process as "free". Much faster.