Reputation: 5039
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
Upvotes: 3
Views: 1097
Reputation: 66244
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
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.
Upvotes: 4
Reputation: 1833
Working with a dynamically allocated block you need to call delete[].
For example:
class C
{
//some members
public:
C() {...}
~C() {...}
// some methods
};
int main()
{
C * arr = new C[10]; // Dynamically allocated memory
// some code using arr . . .
delete[] arr; // Calling ~C() for each C element in arr and then releasing the dynamically alloacted memory on the heap pointed by arr.
}
But, if in addition you have a memeber pointer that was dynamically allocated, you will need to delete it in the destructor of the object:
C::C()
: memberArray(new int[10]) { }
C::~C()
{
delete[] memberArray;
memberArray = NULL;
}
Upvotes: 1
Reputation: 69703
No, the allocated memory will not be released.
When an object which allocated dynamic memory and assigned it to a pointer is deleted, only the pointer will be released, not the data it points to. When an object allocated memory, you must manually call a delete for that data in its destructor, or make sure that it is deleted by some other object which got a pointer to that data.
Deleting it automatically would be impossible, because the object could have passed the allocated data to another object which still needs it after the allocating object was deleted.
Upvotes: 0
Reputation: 248199
The memory freed when you call delete
is just that occupied by the object itself. The object occupies a number of contiguous bytes, and those are released on delete
. sizeof(MyType)
will show you how many bytes that is. And nothing else is released by delete
. Everything else is released by the destructor (or by the destructor of individual member objects)
Upvotes: 1
Reputation: 824
A use of the destructor is that you call the delete
statements for each pointer attributes it contains.
If for example I have a class "car" which has an attribute "tire", which would be a pointer, you would need to delete this attribute in the car's destructor.
Upvotes: 0