在C++11及以后，应同时将拷贝构造函数和拷贝赋值运算符声明为=delete，置于public区；此举可确保编译期报错、语义明确，且不影响移动语义。
如何在 C++11 及以后禁止拷贝
直接将拷贝构造函数和拷贝赋值运算符声明为 delete 是最清晰、最安全的方式。编译器会在任何试图拷贝的地方报错，且错误信息明确指向被删除的函数。
常见错误现象：忘记同时禁用两个函数，导致仅禁用构造函数但还能赋值；或误用 = 0（纯虚）而非 = delete。
- 必须同时禁用两个：
MyClass(const MyClass&) = delete;和MyClass& operator=(const MyClass&) = delete; - 放在类定义内（通常在 public 区域，便于编译器早期诊断）
- 不能只禁用其中一个——否则仍可通过赋值或构造绕过限制
- 继承时子类默认不会自动生成拷贝函数，但若显式定义了，需手动再次
= delete
为什么不用 private + 不实现（C++98/03 方式）
老式写法是把拷贝函数声明为 private 且不提供定义，依赖链接时报错。这种方式问题很多：错误发生在链接阶段而非编译阶段，IDE 不易提示；友元或成员函数仍可意外调用；语义模糊，不如 = delete 明确表达“禁止”意图。
使用场景：仅当必须兼容 C++98 编译器时才考虑，否则毫无优势。
立即学习“C++免费学习笔记（深入）”；
- 编译期错误 vs 链接期错误：后者延迟暴露问题，调试成本高
-
friend函数或类内成员函数仍能调用 private 拷贝函数，破坏设计意图 - Clang/GCC 对
= delete的诊断更精准，比如直接标出哪一行触发了被删除函数
delete 拷贝函数后 move 是否自动禁用
否。= delete 拷贝函数对移动操作完全无影响。只要类满足移动语义条件（未显式禁用移动函数、有可访问的移动构造/赋值），move 依然可用。
性能影响：禁用拷贝不等于禁用所有资源转移；合理启用移动可避免深拷贝开销，尤其对持有堆内存、文件句柄等资源的类。
- 若想同时禁用移动，需额外声明：
MyClass(MyClass&&) = delete;和MyClass& operator=(MyClass&&) = delete; - 某些场景（如单例句柄、非复制资源代理）确实需要禁用全部拷贝与移动
- 注意：禁用拷贝后，容器如
std::vector<myclass></myclass>仍可工作——只要元素支持移动（或使用emplace_back）
常见误用：在模板类中错误地 delete 拷贝
模板类中直接 = delete 拷贝函数可能导致 SFINAE 失效或隐式实例化失败，尤其当模板参数本身不可拷贝时。更稳妥的做法是用 static_assert 或 std::enable_if 控制生成条件。
容易踩的坑：在类模板定义里写 T(const T&) = delete;，结果编译器报错说 “deleted function is not trivially copyable”，实际是模板参数约束没处理好。
- 优先考虑用
static_assert(!std::is_copy_constructible_v<t>, "...");</t>在构造函数体前检查 - 若必须删除，确保
= delete声明不依赖未决模板参数（例如不要写在偏特化外的主模板里） - 对于包装型模板（如
unique_ptr_wrapper），直接= delete是安全的——因为不涉及泛型推导
