破坏的父母和孩子的顺序

Question

为什么C 在Child类之前会破坏Parent类？当对象不符合范围而首先破坏shared_ptr S然后破坏本身时，它是否更合乎逻辑？在我的工作流程中，这会导致问题，因为我的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

破坏顺序定义为(重点是我的(：

对于用户定义或隐式定义的破坏者，执行破坏者的正文后，编译器将所有非静态非变化的distuructor调用，以相反声明的顺序，然后以相反的施工顺序称呼所有直接非虚拟基类的破坏者(依次调用其成员及其基础类别的破坏者等(，然后，如果此对象是最多的，则派生的类，称为所有虚拟基础的毁灭者。

一个良好的理由是，为了释放资源，Parent的破坏者可能需要访问其成员，而不是每个对象都是独立的。

Answer 2

当对象脱离范围时首先破坏shared_ptr，然后破坏本身时，它是否更合乎逻辑？

并不是真的，Parent的驱动器可能需要访问某些成员进行某种清理工作，因此它们需要在构造体主体内访问和活力。如果您需要首先销毁Child，则可以随时手动执行：

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