I have the code:
std::list<Node *> lst; //.... Node * node = /* get from somewhere pointer on my node */; lst.remove(node);
Does the std::list::remove
method call the destructor (and free memory) of each removed element? If so, how I can avoid it?
Yes, though in this case, Node* has no destructor. Depending on its internals though, the various Node* values are either deleted or destroyed by scoping rules.
std::vector does call the destructor of every element it contains when clear() is called. In your particular case, it destroys the pointer but the objects remain.
A destructor is a member function that is invoked automatically when the object goes out of scope or is explicitly destroyed by a call to delete .
Destructors are usually used to deallocate memory and do other cleanup for a class object and its class members when the object is destroyed. A destructor is called for a class object when that object passes out of scope or is explicitly deleted.
Yes, removing a Foo*
from a container destroys the Foo*
, but it will not release the Foo
. Destroying a raw pointer is always a no-op. It cannot be any other way! Let me give you several reasons why.
Deleting a pointer only makes sense if the pointee was actually allocated dynamically, but how could the runtime possibly know whether that is the case when the pointer variable is destroyed? Pointers can also point to static and automatic variables, and deleting one of those yields undefined behavior.
{ Foo x; Foo* p = &x; Foo* q = new Foo; // Has *q been allocated dynamically? // (The answer is YES, but the runtime doesn't know that.) // Has *p been allocated dynamically? // (The answer is NO, but the runtime doesn't know that.) }
There is no way to figure out whether the pointee has already been released in the past. Deleting the same pointer twice yields undefined behavior. (It becomes a dangling pointer after the first delete.)
{ Foo* p = new Foo; Foo* q = p; // Has *q already been released? // (The answer is NO, but the runtime doesn't know that.) // (...suppose that pointees WOULD be automatically released...) // Has *p already been released? // (The answer WOULD now be YES, but the runtime doesn't know that.) }
It is also impossible to detect whether a pointer variable has been initialized at all. Guess what happens when you try to delete such a pointer? Once again, the answer is undefined behavior.
{ Foo* p; // Has p been properly initialized? // (The answer is NO, but the runtime doesn't know that.) }
The type system does not distinguish between a pointer to a single object (Foo*
) and a pointer to the first element of an array of objects (also Foo*
). When a pointer variable is destroyed, the runtime cannot possibly figure out whether to release the pointee via delete
or via delete[]
. Releasing via the wrong form invokes undefined behavior.
{ Foo* p = new Foo; Foo* q = new Foo[100]; // What should I do, delete q or delete[] q? // (The answer is delete[] q, but the runtime doesn't know that.) // What should I do, delete p or delete[] p? // (The answer is delete p, but the runtime doesn't know that.) }
Since the runtime cannot do anything sensible with the pointee, destroying a pointer variable is always a no-op. Doing nothing is definitely better than causing undefined behavior due to an uninformed guess :-)
Instead of raw pointers, consider using smart pointers as the value type of your container, because they take responsibility for releasing the pointee when it is no longer needed. Depending on your need, use std::shared_ptr<Foo>
or std::unique_ptr<Foo>
. If your compiler does not support C++0x yet, use boost::shared_ptr<Foo>
.
Never, I repeat, NEVER EVER use std::auto_ptr<Foo>
as the value type of a container.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With