C++ 怎么禁止拷贝 C++ delete修饰拷贝构造函数【控制】

2026-01-31 00:00:00 作者:尼克
在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 编译器时才考虑,否则毫无优势。

  • 编译期错误 vs 链接期错误:后者延迟暴露问题,调试成本高
  • friend 函数或类内成员函数仍能调用 private 拷贝函数,破坏设计意图
  • Clang/GCC 对 = delete 的诊断更精准,比如直接标出哪一行触发了被删除函数

delete 拷贝函数后 move 是否自动禁用

否。= delete 拷贝函数对移动操作完全无影响。只要类满足移动语义条件(未显式禁用移动函数、有可访问的移动构造/赋值),move 依然可用。

性能影响:禁用拷贝不等于禁用所有资源转移;合理启用移动可避免深拷贝开销,尤其对持有堆内存、文件句柄等资源的类。

  • 若想同时禁用移动,需额外声明:MyClass(MyClass&&) = delete;MyClass& operator=(MyClass&&) = delete;
  • 某些场景(如单例句柄、非复制资源代理)确实需要禁用全部拷贝与移动
  • 注意:禁用拷贝后,容器如 std::vector 仍可工作——只要元素支持移动(或使用 emplace_back

常见误用:在模板类中错误地 delete 拷贝

模板类中直接 = delete 拷贝函数可能导致 SFINAE 失效或隐式实例化失败,尤其当模板参数本身不可拷贝时。更稳妥的做法是用 static_assertstd::enabl

e_if 控制生成条件。

容易踩的坑:在类模板定义里写 T(const T&) = delete;,结果编译器报错说 “deleted function is not trivially copyable”,实际是模板参数约束没处理好。

  • 优先考虑用 static_assert(!std::is_copy_constructible_v, "..."); 在构造函数体前检查
  • 若必须删除,确保 = delete 声明不依赖未决模板参数(例如不要写在偏特化外的主模板里)
  • 对于包装型模板(如 unique_ptr_wrapper),直接 = delete 是安全的——因为不涉及泛型推导
禁用拷贝看似简单,但真正要让行为严格符合预期,关键在于:是否同时覆盖了所有拷贝入口(构造+赋值)、是否考虑了模板上下文、以及是否意识到 delete 对 move 的零影响。这几个点漏掉任何一个,都可能在后续集成中引发难以定位的编译错误或静默行为异常。

猜你喜欢

联络方式:

400 9058 355

邮箱:8955556@qq.com

Q Q:8955556

微信二维码
在线咨询 拨打电话

电话

400 9058 355

微信二维码

微信二维码