破坏父母和孩子的秩序

Question

为什么C ++在Parent类之前破坏了Child类？当一个对象超出范围首先破坏shared_ptrs然后破坏自身时，它是不是更合乎逻辑？在我的工作流程中，这会导致问题，因为我的Parent类正在管理Child类使用的接口。

#include <iostream>
#include <memory>

class Child;

class Parent
{
    public:
        Parent() :
            child(std::make_shared<Child>())
        { 
            std::cout << "Constructing parent" << std::endl;
        }
        ~Parent() { std::cout << "Destructing parent" << std::endl; }
    private:
        std::shared_ptr<Child> child;
};

class Child
{
    public:
        Child()
        { 
            std::cout << "Constructing child" << std::endl;
        }
        ~Child() { std::cout << "Destructing child" << std::endl; }
};

int main()
{
    Parent parent;
    return 0;
}

编辑 根据评论，我觉得我的问题需要更多的解释。我的子类都在std::shared_ptr上分配，当父级超出范围时，它会被释放。我的主程序是CUDA程序，父程序可以访问GPU设备。如果父项被删除，我将无法再访问GPU。然而，孩子们的析构函数需要释放他们的GPU内存，因此我希望在父母退出范围之前采取这一行动。但这意味着我必须手动删除智能指针，在我看来，这有点挫败了他们的目的。

Answer 1

destruction order定义为（强调我的）：

对于用户定义或隐式定义的析构函数，在执行析构函数体之后，编译器按照声明的相反顺序调用类的所有非静态非变体成员的析构函数，然后调用析构函数所有直接的非虚基类按照构造的相反顺序（反过来调用它们的成员及其基类的析构函数等），然后，如果这个对象是派生最多的类，它调用所有虚拟的析构函数基地。

一个很好的理由是Parent的析构函数可能需要访问其成员以释放资源，而不是每个对象都是自包含的。

Answer 2

当一个对象超出范围首先破坏shared_ptrs然后自毁时，它是否更合乎逻辑？

不是真的，Parent的析构函数可能需要访问某些成员来进行某种清理，因此它们需要在构造函数体内可访问和存活。如果您需要先破坏Child，您可以随时手动执行：

~Parent() { 
  child.reset();
  // do the rest ...
}