delete拷贝构造函数后仍能编译通过，是因为编译器在拷贝被禁用时可能转而尝试移动；若移动也未定义，则报错——并非拷贝未禁用，而是退路缺失。
为什么 delete 拷贝构造函数后仍能编译通过？
常见错觉是：只要写了 MyClass(const MyClass&) = delete;，就彻底禁用了拷贝。但实际中，如果类里没显式定义移动构造函数，而你又试图用右值初始化（比如返回临时对象），编译器可能因“删除了拷贝但没提供移动”而报错——不是因为拷贝没禁掉，而是它想退而求其次用移动，结果发现连移动也没有。
实操建议：
- 禁用拷贝时，务必同步考虑移动语义：要么也
= delete移动构造/赋值，要么显式定义它们 - 若类本就不该被拷贝或移动（如封装了唯一资源句柄），两个都删更安全
- 注意基类影响：若基类的拷贝构造函数是
protected或private，派生类即使没声明拷贝函数，也会隐式删除（编译失败）
= delete 放在 public 还是 private 区域？
必须放在 public 区域。很多人误以为“删掉就该藏起来”，于是写成 private: MyClass(const MyClass&) = delete; ——这反而会让错误信息变模糊：编译器先报“访问私有成员”，而不是“已删除”。用户无法第一时间意识到是设计上禁止拷贝，容易绕弯排查。
正确写法：
立即学习“C++免费学习笔记（深入）”；
class NonCopyable {
public:
NonCopyable() = default;
NonCopyable(const NonCopyable&) = delete; // ← 必须 public
NonCopyable& operator=(const NonCopyable&) = delete;
};
补充说明：
-
= delete的函数即便在public区，也无法被调用；它的可见性只影响错误提示的清晰度 - 不要用
private+ 空实现替代= delete：后者能在编译期拦截，前者拖到链接期甚至运行期才暴露问题
哪些场景下 = delete 比传统 private 声明更关键？
模板类或泛型代码中，= delete 是唯一可靠手段。例如你写了一个容器模板，想禁止对某些类型（如 std::unique_ptr）做拷贝构造：
templateclass Box { Box(const Box &) = delete; // 错！太粗暴，所有 T 都禁了 template Box(const Box&) = delete; // 也不行：SFINAE 不适用 delete 声明 };
更合理的做法是结合 std::is_copy_constructible_v 和 static_assert，或对特化类型单独 = delete。但重点在于：= delete 是编译期强制策略，而传统 private 在模板实例化时可能根本不会触发（取决于是否被调用）。
其他典型场景：
- 禁用特定参数类型的重载（如禁止从
int构造）：MyClass(int) = delete; - 禁用隐式转换构造函数，避免意外类型提升
- 防止
std::vector因内部拷贝操作失败而编译不过
继承 NonCopyable 基类时的坑
很多项目沿用旧式 boost::noncopyable 风格：基类把拷贝相关函数设为 private。但 C++11 后这已过时。问题在于：派生类若未显式声明拷贝构造函数，编译器会尝试合成——而合成规则要求基类的对应函数可访问。基类是 private，合成失败，报错信息却是 “use of deleted function”，非常误导。
现代写法应直接在派生类中 = delete：
class Widget : private NonCopyable { // ❌ 旧习惯，隐患多
// ...
};
换成：
class Widget {
public:
Widget(const Widget&) = delete;
Widget& operator=(const Widget&) = delete;
// 其他成员...
};
真正容易被忽略的是：如果派生类有成员变量是不可拷贝类型（如 std::unique_ptr），即使你不写任何 = delete，编译器也会自动删除拷贝构造函数——但这个隐式删除不等于“你控制了行为”，一旦后续加了可拷贝成员，它又悄悄复活，导致行为不一致。
