Question

This question may sound too simple to some guys, but I am trying to understand what happens if I delete an object having a dynamically allocated block using delete keyword

Calling a delete will do 2 things, first call the destructor and then release the memory.
If delete is releasing the object memory then will it also release the dynamic allocated memory or would I have to write a block of code in destructor to actually release the memory block safely.

Also if objects are allocated memory in heap then what other things other than member variables will take up the memory allocated to the object.

Thanks in advance

Answer 1

If you have something like this:

class Foo
{
public:
   int* block;

   Foo()
   {
       block = new int[10];
   }

private:
   Foo(const Foo&);
   Foo& operator =(const Foo&);
};

And subsequently do this:

Foo* foo = new Foo;
delete foo;

Then yes, you’re leaking memory. The dynamic block in your Foo object is never released. You can address this with a destructor that releases it. (of source, you need to declare the destructor in the class declaration as well):

Foo::~Foo()
{
    delete [] block;
}

I would advise you to do two things

1. Count the delete’s and the new’s. if they’re not the same, thats generally a problem.
2. Read this informative document on dynamic pointer and memory usage with C++.

Following #2, btw, might give you an object that looks similar to this:

class Foo
{
public:
   std::array<int,10> block;

   Foo() // note: default-construction of `block`
   {
   }

   // note: default *destructor* will clean up member variables
   //  by firing their destructors for you. in this case the destructor
   //  for our 'block' member is a std::array that knows how to self-clean.

   // note: we no longer have to hide or implement copy construction and
   //  assignment operator functionality. The default implementation of 
   //  these properly member-copy and member-assign respectively.
};

And a usage (one of many possibilities) like this:

std::unique_ptr<Foo> foo(new Foo);

Please regard the notes in the source of the last example. There is a tremendous weight lifted off your memory-management shoulders by using classes that practice self-managed members. In lifting that weight, so too goes the per-chance likelihood of introducing bugs related to it, like memory leaks, shallow-copy perils, etc.