Does std::list::remove method call destructor of each removed element?

Question

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?

Subtotal

Why are you storing pointers in the first place? – Palais

Answer 1

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.

Storage class

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.)
}

Dangling pointers

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.)
}

Uninitialized pointers

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.)
    }

Dynamic arrays

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.)
}

Summary

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 :-)

Advice

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.

Interlink

Answer 2

It calls the destructor of each of the items in the list -- but that's not a Node object. Its a Node*.

So it doesn't delete the Node pointers.

Does that make sense?

Fatality

But I have a 'Segementation fault' if I try to delete node after remove calling. :( Why it happened? – Subtotal

@JohnDibling It is clear that the object will not be delete-ed when its raw-pointer is erased from a container. But will it call destruct-or of the object? I think this should not be the case. But the docs say that destructor is called for the map element being deleted. – Kipkipling

Answer 3

It does call the destructor of the data in the list. That means, std::list<T>::remove will call the destructor of T (which is necessary when T is something like std::vector).

In your case, it would call the destructor of Node*, which is a no-op. It doesn't call the destructor of node.

Inexpressible

Yes. For extra clarity, the code example shown does not call Node::~Node and does not delete the node pointer. (Though if you had an iterator to that place in the list, it is now invalid.) – Hustings

Answer 4

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. If Node* where some non-fundamental type, a destructor would be called.

Is the destructor called on the Node? No, but 'Node' is not the element type in the list.

As to your other question, you can't. The standard list container (in fact ALL standard containers) adopt ownership of their content and will clean it up. If you don't want this to happen, the standard containers are not a good choice.

Calorie

Answer 5

Since you are putting pointers into a std::list, destructors are not called on the pointed-to Node objects.

If you want to store heap allocated objects in STL containers and have them be destructed upon removal, wrap them in a smart pointer like boost::shared_ptr

Holocaine

Answer 6

The best way to understand is to test each form and observe the results. To skillfully use the container objects with your own custom objects you need to have a good understanding of the behavior.

In short, for the type Node* neither the deconstructor is called nor delete/free is invoked; however, for the type Node the deconstructor would be invoked while consideration of delete/free is an implementation detail of list. Meaning, it depends on if the list implementation used new/malloc.

In the case of a unique_ptr<Node>, the deconstructor is invoked and the calling of delete/free will happen since you had to give it something allocated by new.

#include <iostream>
#include <list>
#include <memory>

using namespace std;

void* operator new(size_t size) {
    cout << "new operator with size " << size << endl;
    return malloc(size);
}

void operator delete(void *ptr) {
    cout << "delete operator for " << ptr << endl;
    free(ptr);
}

class Apple {
public:
    int id;

    Apple() : id(0) { cout << "apple " << this << ":" << this->id << " constructed" << endl; } 
    Apple(int id) : id(id) { cout << "apple " << this << ":" << this->id << " constructed" << endl; }
    ~Apple() { cout << "apple " << this << ":" << this->id << " deconstructed" << endl; }

    bool operator==(const Apple &right) {
        return this->id == right.id;
    }

    static void* operator new(size_t size) {
        cout << "new was called for Apple" << endl;
        return malloc(size);
    }

    static void operator delete(void *ptr) {
        cout << "delete was called for Apple" << endl;
        free(ptr);
    }
    /*
        The compiler generates one of these and simply assignments
        member variable. Think memcpy. It can be disabled by uncommenting
        the below requiring the usage of std::move or one can be implemented.
    */
    //Apple& operator=(const Apple &from) = delete;
};

int main() {
    list<Apple*> a = list<Apple*>();

    /* deconstructor not called */
    /* memory not released using delete */
    cout << "test 1" << endl;
    a.push_back(new Apple());
    a.pop_back();

    /* deconstructor not called */
    /* memory not released using delete */
    cout << "test 2" << endl;
    Apple *b = new Apple();
    a.push_back(b);
    a.remove(b);
    cout << "list size is now " << a.size() << endl;

    list<Apple> c = list<Apple>();      
    cout << "test 3" << endl;
    c.push_back(Apple(1)); /* deconstructed after copy by value (memcpy like) */
    c.push_back(Apple(2)); /* deconstructed after copy by value (memcpy like) */

    /*
       the list implementation will call new... but not
       call constructor when Apple(2) is pushed; however,
       delete will be called; since it was copied by value
       in the last push_back call

       double deconstructor on object with same data
    */
    c.pop_back();

    Apple z(10);

    /* will remove nothing */
    c.remove(z);

    cout << "test 4" << endl;

    /* Apple(5) will never deconstruct. It was literally overwritten by Apple(1). */
    /* Think memcpy... but not exactly. */
    z = Apple(1);

    /* will remove by matching using the operator== of Apple or default operator== */
    c.remove(z);

    cout << "test 5" << endl;
    list<unique_ptr<Apple>> d = list<unique_ptr<Apple>>();
    d.push_back(unique_ptr<Apple>(new Apple()));
    d.pop_back();

    /* z deconstructs */
    return 0;
}

Pay careful attention to the memory addresses. You can tell which are pointing into the stack and which are pointing into the heap by the ranges.

Callboard