Is delete necessary in a destructor?

Question

I have the following code and I'm wondering if that delete b is necessary here ? Will my operating system automatically clear that area of memory allocated ?

class A
{
    B *b;

    A()
    {
        b = new B();
    }

    ~A() 
    {
        delete b;
    }
};

Many thanks.

Answer 1

Yes, you have to delete every object created with new that you own. In this very case it looks like class A owns that very instance of class B and is responsible for calling delete.

You'll be much better off using a smart pointer for managing class B instance lifetime. Also note that you have to either implement or prohibit assignment operator and copy constructor in class A to prevent shallow copying the object which will cause you much trouble.

Answer 2

Probably your operating system will free the allocated memory - but this is done when your program exits. Long running programs will run into memory issues.

It's always a good idea to use smart pointers for dynamically allcoated objects. These will do all the delete stuff for you.

• std::auto_ptr
• boost::shared_ptr
• boost::scoped_ptr

Answer 3

It's certainly necessary the way you've written it. Even with the delete, though, the class is fundamentally broken because it manages a resource but doesn't follow the rule of three.

That said, there's almost certainly no reason for manual memory management--there rarely is. It's likely that you should either just have a B object as a member variable, or you should be using a smart pointer, like QScopedPointer:

struct A
{
    QScopedPointer<B> b;
    A() : b(new B()) { }

    // No ~A() needed; when the A object is destroyed, QScopedPointer ensures 
    // that the B object pointed to by the member 'b' is destroyed and deleted.
};

You'll want to make sure that you have a good introductory C++ book so that you can learn how to write correct C++ programs.

Answer 4

If you call a new, corresponding delete is always advisable.

As far as operating system deleting your memory.. yes, it will happen but only after the entire process terminates (i.e. your application exits). Only then all memory and other resources are reclaimed by the OS.

Thirdly, try to use new/delete only when necessary. In your scenario, you could just write

class A 
{

B b;

  A() {}

  ~A() {}

};

It would have the same effect and you avoid an extra dynamic memory allocation.

Answer 5

It will clear the area only when the process ends, but the area will remain allocated all the time until then, which means memory leak.

Answer 6

The b member will be allocated on heap. It is true that the operating system will free all the memory occupied by heap; however that will happen only once: on program exit.

So if you don't free the allocated heap blocks the very time they become unused (typically in destructor of some object), you are risking to get a memory leak.

So the answer is basically: yes, you have to call delete manually, as the memory won't be freed ASAP automagically (though smart-pointers will help you to achieve something similar).

Answer 7

Anything that you allocate with new you should free with delete, otherwise there is a memory leak in your application.

On most modern operating systems (certainly the OSes that people usually run on desktop computers) anything that a process uses will be cleaned up when the process ends, so if you forget a delete, then the memory will be freed anyway. However you should not rely on this.

Long ago I programmed on the Amiga in C. Its operating system was much less sophisticated than today's operating systems. If you'd allocate memory and not free it, it would stay allocated until you switched off or rebooted the computer, even after the process had ended. Memory leaks were an even more serious problem then.

Answer 8

Resource management is more than just deallocating memory. Yes, most platforms will make any memory you allocate when the process ends, and memory is cheap enough that maybe you won't notice for a while. But what about the file b is holding open, or the mutex it will unlock in its destructor? Well before you run out of memory, you can encounter issues from letting your objects live past their usefullness.

Answer 9

1) Long-running applications will run into problems, because the OS can only reclaim the memory when the application stops running.

2) delete b; also causes the destructor of the pointed-at B instance to run. Otherwise it will never run, since there is no longer any way to get at it. That destructor might do something important.