为何定义析构函数时移动构造函数会被隐式删除？规则合理性探讨

咱们先从你贴的代码说起：当你给struct A加了一个空析构函数~A(){};之后，编译器就拒绝自动生成默认的移动构造函数了。这时候A b = std::move(a);会尝试调用拷贝构造，但std::unique_ptr是不可拷贝的，自然就编译报错了。

这个规则可不是随便定的，C++标准委员会的逻辑非常务实：如果你需要自己写析构函数，说明这个类大概率涉及手动资源管理——比如你要在析构里释放堆内存、关闭文件句柄、清理网络连接之类的。默认生成的移动构造函数只是简单地逐成员移动，但它完全不知道你析构函数里的自定义逻辑，很容易搞出问题：比如你写了一个封装文件句柄的类，默认移动只会把句柄值复制过去，原来的对象析构时又会调用close()，直接导致重复关闭的错误。

那这个「不默认生成移动成员」的规则，到底适合哪些场景呢？

• 手动管理资源的类：这是最典型的场景。比如你封装了一个自定义的内存池、或者一个绑定了硬件设备的句柄，析构函数里有专属的资源清理逻辑。默认移动构造根本无法适配你的需求，甚至会引发双重释放、资源泄漏这类致命问题。标准干脆不生成默认移动，逼着你自己写符合业务逻辑的版本，确保移动后原对象的资源被正确置空，避免后续析构时出问题。
• 设计为不可移动的类：有些类从语义上就不应该被移动——比如代表线程本地存储的类、或者一个绑定了特定进程状态的工具类。这时候哪怕你只写一个空的析构函数，就能顺带禁用默认移动构造，完美契合类的设计意图，避免使用者误操作。
• 需要精确控制对象状态的RAII类：比如你写了一个RAII类，除了析构时释放资源，还要统计当前存活的对象数量、维护全局状态之类的。默认移动构造函数只会逐成员移动，根本不会帮你更新这些额外的状态。这时候标准不生成默认移动，让你自己实现包含状态更新逻辑的移动构造，保证类的行为符合预期。

如果你想让你的示例代码支持移动语义，其实很简单，显式默认移动构造函数就行：

struct A {
    ~A(){};
    std::unique_ptr<int> a;
    // 显式告诉编译器生成默认移动构造
    A(A&&) = default;
};

内容的提问来源于stack exchange，提问作者Gabriel