C++ std::list::remove 方法是否调用每个已删除元素的析构函数？

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

提问by Siarhei Fedartsou

I have the code:

我有代码：

std::list<Node *> lst;
//....
Node * node = /* get from somewhere pointer on my node */;
lst.remove(node);

Does the std::list::removemethod call the destructor (and free memory) of each removed element? If so, how I can avoid it?

该std::list::remove方法是否调用每个删除元素的析构函数（和空闲内存）？如果是这样，我该如何避免？

回答by fredoverflow

Yes, removing a Foo*from a container destroys the Foo*, but it will not release the Foo. Destroying a raw pointer is alwaysa no-op. It cannot be any other way! Let me give you several reasons why.

是的，Foo*从容器中删除 a会破坏Foo*，但不会释放Foo。销毁原始指针始终是无操作的。它不可能是任何其他方式！让我给你几个原因。

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 pointerafter 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.

也根本无法检测指针变量是否已被初始化。猜猜当您尝试删除这样的指针时会发生什么？再一次，答案是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 deleteor via delete[]. Releasing via the wrong form invokes undefined behavior.

类型系统不区分指向单个对象Foo*的指针( ) 和指向对象数组的第一个元素的指针 (也Foo*)。当指针变量被销毁时，运行时可能无法确定是通过delete还是通过释放指针对象delete[]。通过错误的形式发布会调用未定义的行为。

{
    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 alwaysa 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>.

考虑使用智能指针作为容器的值类型，而不是原始指针，因为它们负责在不再需要指针时释放指针。根据您的需要，使用std::shared_ptr<Foo>或std::unique_ptr<Foo>。如果您的编译器还不支持 C++0x，请使用boost::shared_ptr<Foo>.

Never, I repeat, NEVER EVERuse std::auto_ptr<Foo>as the value type of a container.

从来没有，我再说一遍，永远不要使用std::auto_ptr<Foo>作为容器的值类型。

回答by John Dibling

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

它调用 - 中每个项目的析构函数，list但这不是一个Node对象。它的一个Node*.

So it doesnt delete the Nodepointers.

所以它不会删除Node指针。

Does that make sense?

那有意义吗？

回答by jpalecek

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

它确实调用了列表中数据的析构函数。这意味着，std::list<T>::remove将调用的析构函数T（在T类似于时这是必要的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.

在您的情况下，它会调用 的析构函数Node*，这是一个无操作。它不会调用 的析构函数node。

回答by Edward Strange

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.

是的，尽管在这种情况下，Node* 没有析构函数。但是，根据其内部结构，各种 Node* 值会被范围规则删除或销毁。如果 Node* 包含一些非基本类型，则会调用析构函数。

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.

至于你的另一个问题，你不能。标准列表容器（实际上是所有标准容器）采用其内容的所有权并将其清理。如果您不希望这种情况发生，标准容器不是一个好的选择。

回答by wkl

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

由于您将指针放入 a std::list，因此不会在指向的Node对象上调用析构函数。

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

如果您想将堆分配的对象存储在 STL 容器中并在移除时销毁它们，请将它们包装在一个智能指针中，如 boost::shared_ptr

回答by kmcguire

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 Nodethe 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.

简而言之，对于该类型Node*既不调用析构函数也不调用 delete/free；然而，对于类型Node，将调用解构器，而考虑删除/释放是列表的实现细节。意思是，这取决于列表实现是否使用了 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.

在 a 的情况下unique_ptr<Node>，析构函数被调用，delete/free 的调用将发生，因为你必须给它分配的东西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.

请特别注意内存地址。您可以通过范围判断哪些指向堆栈，哪些指向堆。