[solved] memory deallocation and the delete keyword
-
NO!!
@delete pointer@
actually calls the destructor and releases the memory.
Setting it equal to 0, would let the pointer point to the object at address 0 (your object will never be at address 0). If you don't call delete, the object will still exist in memory, but you can't access it anymore. Thus, you created a memory leak. Setting it equal to 0 after deleting is useful for checking whether the object exists. E.g.@
if(someCondition)
{
delete pointer;
pointer = 0;
}//and later
if(pointer)
{
//the object still exists, i.e. you can safely use it
}else
{
//it doesn't, do something else
}
@ -
No, just setting the pointer to 0 does not delete the object.
That's a good thing™!
Assume the following code:
@
MyClass *pointer = new MyClass;MyClass *alias = pointer;
alias = 0;pointer->doSomething();
@The call to doSomething would fail, if the object had been deleted by assigning 0 to alias.
Resetting the pointer to 0 after a delete can be a good practice in case the pointer can be accessed afterwards. If it had its previous value, using the pointer would lead to a segmentation fault, because the old object is no longer valid. To avoid a null pointer exception, you should check the pointer for being no-null of course :-)
-
[quote author="mlong" date="1313088302"]Wow... this is definitely a hot-button issue! :-) I love the different details which accent each explanation of the core issue.[/quote]
Indeed. When I was done typing there were already two other replies and 20sec later Volker's came to ;). At least one can say we are an active community. Where else do you get 4 elaborate answers within 10min?
-
In addition, deleting objects that already have been deleted result in an error, whereas deleting a null pointer does not. So setting the pointer to 0 after it has been deleted is good practice.
@
QObject* object = new QObject;delete object; // OK
delete object; // FAIL
// ...
QObject* object = new QObject;
delete object; // OK
object = 0;delete object; // OK
@ -
[quote author="loladiro" date="1313088523"]
Indeed. When I was done typing there were already two other replies and 20sec later Volker's came to ;). At least one can say we are an active community. Where else do you get 4 elaborate answers within 10min?[/quote]
For best frameworks best community :-) -
thank you for your answers
so if i call delete and then allocate to 0,my pointer will point to an invalid address but i will have a mem leak.Correct?
So,if i call delete in my destructor there is no reason to allocate 0 to my pointer.Is that correct?
-
Summary:
@
pointer = 0;
@
Memory leak;@
delete pointer;
@
No memory leak, but no way of detecting it was deleted (and, as Lukas pointed out, calling delete again will result in an error).@
delete pointer;
pointer = 0;
@
No memory leak, you can check whether it still exists with if(pointer)[quote]
So,if i call delete in my destructor there is no reason to allocate 0 to my pointer.Is that correct?
[/quote]
Correct (at least as long the pointer itself is not shared with other objects. Then it gets complicated) -
You will have a leak if you set pointer to 0 and then delete it.
[quote author="Giorgos Tsiapaliwkas" date="1313089184"]
So,if i call delete in my destructor there is no reason to allocate 0 to my pointer.Is that correct?[/quote]
This is correct, cuz after destructor you will not need a pointer at all. -
If you create a new object using new a block of memory for this desired object is allocated (which means memory is taken from a large pool and reserved for this object) and the address of this memory block is stored to the pointer variable.
If you delete the object using delete the block of memory is returned to the memory pool and can be taken by another object. You pointer still points to the address of the memory where your object was previously stored. If you now access the object through this pointer your program will crash, as the object does no longer exist at this address in memory. This is why you should assign the address 0 the pointer, which indicates that this pointer does not address a valid block of memory.
You do not call delete within your destructor. If you call delete on an object the destructor for this is called by the delete operation.
[quote author="rokemoon" date="1313089462"]You will have a leak if you set pointer to 0 and then delete it.
[quote author="Giorgos Tsiapaliwkas" date="1313089184"]
So,if i call delete in my destructor there is no reason to allocate 0 to my pointer.Is that correct?[/quote]
This is correct, cuz after destructor you will not need a pointer at all.
[/quote]No, you never ever call delete on the object which is currently destructed.
-
And just for future read "this":http://doc.qt.nokia.com/latest/qscopedpointer.html and "this":http://doc.qt.nokia.com/latest/qsharedpointer.html. This will help you not to worry about manually deletion.
-
[quote author="rokemoon" date="1313089726"]And just for future read "this":http://doc.qt.nokia.com/latest/qscopedpointer.html and "this":http://doc.qt.nokia.com/latest/qsharedpointer.html. This will help you not to worry about manually deletion.[/quote]
Caveat: Smart pointers are great tools to help manage the lifespan of objects, but they still require a base knowledge of what pointers are all about at their lowest level. It's important to make sure that you have a grasp of the fundamentals before using the higher-level counterparts, though. That's just IMHO, though.
-
[quote author="mlong" date="1313090165"]
Caveat: Smart pointers are great tools to help manage the lifespan of objects, but they still require a base knowledge of what pointers are all about at their lowest level. It's important to make sure that you have a grasp of the fundamentals before using the higher-level counterparts, though. That's just IMHO, though.
[/quote]I cannot but second this!
So we have the outline for next year's "DevDays T-Shirts":http://developer.qt.nokia.com/forums/viewreply/50309/ :) :) :) -
[quote author="Lukas Geyer" date="1313089715"]
No, you never ever call delete on the object which is currently destructed.[/quote]if i have this
@class a {
private:
BClass* pointer;
};@then it is correct to do the following,right?
@~a::a(){
delete pointer;
}@the follow is true or false?
@delete pointer;
pointer=0;if (pointer) {
....}@ -
[quote author="Giorgos Tsiapaliwkas" date="1313091362"]
if i have this
@class a {
private:
BClass* pointer;
};@then it is correct to do the following,right?
@~a::a(){
delete pointer;
}@the follow is true or false?
@delete pointer;
pointer=0;if (pointer) {
....}@[/quote]
@~a::a(){
delete pointer;
}@should be this
@a::~a(){ // the ~ is not the class name it's parte of the function name
delete pointer;
}@the rest is ok.
EDIT:
Excurse: it's always- returntype classname::functionname(parameters)
and constructors and destructors have no return type :-)
-
Indeed.
I think the point that Lukas was making here:
bq. No, you never ever call delete on the object which is currently destructed.
Was that you'd never have the situation of:
@
a::~a() {
// BAD CODE:
delete this; // You would never delete an item from within its own destructor.
}
@(At least that's what I took it to mean.)
-