Effective C 里的条款十二原话是“复制对象时勿忘其每一个成分”。这句话放在书里并不起眼既不像条款05、06那样讲构造与析构的边界也不像条款13、14那样直接讨论资源管理的大框架它更像一条朴素的审计纪律只要你在类里手写了拷贝构造函数或拷贝赋值运算符就必须手工保证对象的每一个成分都被复制过去一个也不能少。听起来像废话但在实际项目里我见过太多因为这个“废话”翻车的例子加了新成员忘了更新拷贝函数派生类拷贝构造漏掉基类部分资源管理类里浅拷贝导致双重释放。这题同时也是C面试高频八股点很多人能背出“勿忘其每一个成分”这句话真到写代码时就漏。这篇文章不背概念用几个最典型的翻车现场把条款讲透最后给你一套能直接抄的检查方法。1. 条款十二到底在说什么拷贝函数的“完整性”问题1.1 从“成分”这个词说起在Effective C的语境里“成分”指的是一个对象中包含的每一块独立状态。大致可以分成三类非静态数据成员、直接基类子对象、以及资源所有权语义。非静态数据成员最好理解就是类里声明的那些 int、string、vector、指针成员直接基类子对象指的是继承体系里父类的那一份状态资源所有权语义则更隐蔽如果某个成员管理了堆内存、文件句柄、socket那么“复制”还包含如何处理这份资源的所有权或引用计数。这里要盯住两个函数拷贝构造函数和拷贝赋值运算符。条款十二提醒的是这两个函数必须把对象里所有的成分都完整复制而不是“差不多复制”。比如下面这个类看起来无懈可击class User { public: User(const std::string n, int l) : name(n), level(l) {} User(const User rhs) : name(rhs.name), level(rhs.level) {} User operator(const User rhs) { name rhs.name; level rhs.level; return *this; } private: std::string name; int level; };问题在哪假设后续迭代给 User 增加了一个 bool vip; 成员而你没有同步更新拷贝构造和拷贝赋值。结果User b(a);或b a;之后b.vip 可能还是默认初值和 a.vip 完全不是一个状态。编译器不会给你任何警告因为代码在语法和类型层面都合法。1.2 为什么编译器不帮你兜底很多人第一次听到这里会问编译器连类型都能查为什么不能检测“漏了一个成员”原因是默认拷贝函数和自定义拷贝函数是互斥关系。你没有写拷贝函数时编译器会生成一份默认版本自动复制所有非静态数据成员一旦你亲手写了编译器就认为你想接管这份工作于是原样保留你的逻辑不再生成也不再校验“完整性”。编译器擅长检查类型、语法、约束条件却无法判断你写的拷贝函数是否覆盖了全部成员——这是一种语义完整性只能靠人脑保证。拿生活类比默认拷贝函数像是硬盘整盘克隆划拉一下就全过去了自定义拷贝函数则是你手动挑文件复制少选一个文件文件系统不会提醒你。这正是条款十二存在的根本原因它要求你在手写拷贝函数时用“列出所有成分并逐一核对”的方式来写代码而不是凭感觉。2. 最常见的翻车现场漏掉基类成分与新成员2.1 派生类复制时忘记基类部分经典事故派生类的拷贝问题是我在Code Review里看到最多的一类。看这段代码class Base { public: Base(int x) : x_(x) {} Base(const Base rhs) : x_(rhs.x_) {} Base operator(const Base rhs) { x_ rhs.x_; return *this; } private: int x_; }; class Derived : public Base { public: Derived(int x, int y) : Base(x), y_(y) {} Derived(const Derived rhs) : y_(rhs.y_) {} // 错误 Derived operator(const Derived rhs) { // 错误 if (this ! rhs) { y_ rhs.y_; } return *this; } private: int y_; };Derived的拷贝构造初始化列表里没有调用Base(rhs)那么基类部分会走Base的默认构造函数。如果Base没有默认构造编译会直接失败错误暴露得还算早麻烦的是Base有默认构造函数、且x_初始成 0 的情况编译完全通过但复制后基类字段不是源对象的值程序行为悄悄出错。拷贝赋值同理。Derived::operator里没有调用Base::operator基类部分就保留旧值派生类对象变成“半更新”状态。正确写法是在初始化列表里显式调用基类拷贝构造在赋值体里显式调用基类拷贝赋值Derived(const Derived rhs) : Base(rhs), y_(rhs.y_) {} Derived operator(const Derived rhs) { if (this ! rhs) { Base::operator(rhs); y_ rhs.y_; } return *this; }注意赋值体里用的是Base::operator(rhs)加限定名否则编译器会把它看作Derived::operator又变成递归调用。2.2 新增成员后未同步更新拷贝函数另一种高频事故是“老代码加新成员”。项目刚开始类只有两三个字段手写拷贝函数还能顾得过来某天给Config加了timeout_ms拷贝构造和拷贝赋值却忘改了。这种bug在代码评审里很难一眼发现因为拷贝函数通常不长不短Reviewer的注意力容易集中在业务逻辑上谁会逐行核对新增成员有没有出现在两处赋值语句里除非成员声明顺序和拷贝函数顺序完全一致否则肉眼很容易漏。我的实操建议是手写拷贝函数时把成员按声明顺序一个一个写写完再对照头文件里的成员声明清单重新过一遍。但人肉核对终究有漏洞更靠谱的是把“一致性测试”做进CI后文会细说。2.3 用 default 和删除拷贝来根治低频错误既然手写容易漏C11之后最有效的方案就是把拷贝函数交给编译器class Config { public: Config(const Config) default; Config operator(const Config) default; };默认拷贝函数自动复制全部非静态数据成员今天加一个成员明天加一个成员都不会漏。这其实已经成了现代C团队的共识能 default 就 default不能 default 才手写。反过来如果类不应该被复制比如持有互斥锁、std::unique_ptr就明确删除class MutexGuard { public: MutexGuard(const MutexGuard) delete; MutexGuard operator(const MutexGuard) delete; };删除拷贝比“不声明”更清晰编译报错信息直接告诉你这个类不可拷贝而不是让你在“好像没用到拷贝”的侥幸中埋雷。3. 拷贝构造与拷贝赋值之间的“暗线”互相调用必翻车3.1 在拷贝赋值中调用拷贝构造无限递归的栈溢出有开发者为了让赋值复用构造逻辑写出这种代码class Widget { public: Widget(const Widget rhs) { /* 逐成员复制 */ } Widget operator(const Widget rhs) { *this Widget(rhs); // 错误 return *this; } };Widget(rhs)构造临时对象没问题但*this Widget(rhs);这个赋值动作又调用了operator于是陷入“operator → 构造临时对象 → operator → 构造临时对象……”的无限递归最终栈溢出。这种错误实际运行时往往表现为 “莫名其妙的 stack overflow”而不是编译错误。排查时看到operator函数体里有*this xxx基本就锁定了。正确做法是直接逐成员复制不要绕道赋值Widget operator(const Widget rhs) { if (this ! rhs) { member1 rhs.member1; member2 rhs.member2; } return *this; }3.2 在拷贝构造中调用拷贝赋值看似可行实则全错反向操作也有人尝试Widget(const Widget rhs) { *this rhs; // 试图复用operator }这里至少有三个问题。第一拷贝构造时对象还没构建完成先用默认构造初始化了一版再调用operator去覆盖相当于白做了一次默认构造效率低。第二如果类里有const成员或引用成员operator根本无法给它们赋值编译直接失败因为引用和const成员只能初始化不能赋值。第三就算编译过了如果operator里只复制成员而忽略了基类部分拷贝构造的“基类初始化”也会出问题。更本质的原因在于拷贝构造是“从无到有”拷贝赋值是“从有到有”两者面对的初始状态完全不同。互相调用都不是正道条款十二的精髓就是把它们当两个独立的完整复制流程来写。3.3 copy-and-swap一份代码同时服务两个拷贝函数真正解决两者代码重复问题的是 copy-and-swap 惯用法核心是用“传值参数”复用拷贝构造再用 swap 交换内部状态。class Widget { public: Widget(const Widget rhs); Widget operator(Widget rhs) { // 参数按值触发拷贝构造或移动构造 swap(rhs); return *this; } void swap(Widget rhs) noexcept { using std::swap; swap(member1, rhs.member1); swap(member2, rhs.member2); } };分析一下这个模式调用w2 w1时w1作为左值被复制到参数rhs触发拷贝构造调用w2 std::move(w1)时触发移动构造operator内直接交换旧状态被交换到临时对象里临时对象析构时自动释放旧资源只要swap是 noexcept赋值过程就不会抛异常天然具备强异常安全。但注意copy-and-swap 的前提是swap本身也要“完整交换每一个成分”。如果swap漏掉某个成员等价于复制函数漏掉成分一样是埋雷。所以写类内swap时同样要逐成员核验。4. 资源管理类里的“成分”不止是成员变量4.1 浅拷贝 vs 深拷贝漏掉资源所有权就是隐患条款十二往深了走会撞上资源管理。假设你有一个裸指针成员表面上你复制了指针这个成分但“成分”的语义还可能包括“指针指向的数据”以及“这份数据归谁所有”。经典案例class String { public: String(const char* s) { len strlen(s); data new char[len 1]; strcpy(data, s); } // 默认拷贝构造是浅拷贝data指针被复制但指向的同一块内存 // String(const String rhs) : len(rhs.len), data(rhs.data) {} ~String() { delete[] data; } private: char* data; int len; };如果使用默认浅拷贝两个String的data指向同一块堆内存两个析构函数都执行delete[]这就是 double free。更严谨地说这种状态下任何对data的访问都是未定义行为。问题根源就在于“复制了指针却忘了复制它指向的数据”。正确深拷贝是String(const String rhs) : data(new char[rhs.len 1]), len(rhs.len) { strcpy(data, rhs.data); }可以看到深拷贝里的“成分”至少包含len、data、以及data指向的那块内存。写拷贝函数时除了列成员声明还要追问一句每个指针成员的“资源深度”是否需要一起复制是唯一所有权还是共享所有权当然现代C的答案是用std::string、std::vector、std::unique_ptr这些管理类让它们的拷贝语义替你回答“成分”。手写裸指针资源管理类已经是上个时代的做法现在的C代码里出现裸指针成员本身就是一个危险信号。4.2 自研引用计数时的复制坑在std::shared_ptr普及之前很多人用引用计数避免深拷贝。如果自己维护一个int* refCount那么拷贝构造时除了复制普通成员还多了一个“成分”计数要递增。class SharedBuffer { public: SharedBuffer(const SharedBuffer rhs) : data(rhs.data), refCount(rhs.refCount) { (*refCount); // 忘了这个就完蛋 } SharedBuffer operator(const SharedBuffer rhs) { if (this ! rhs) { --(*refCount); if (*refCount 0) { delete data; delete refCount; } data rhs.data; refCount rhs.refCount; (*refCount); } return *this; } private: char* data; int* refCount; };在这个例子里“每一个成分”不仅指data和refCount两个指针还包含运行时的共享计数状态。很多人漏掉(*refCount)或者漏掉先自减旧计数导致技术错乱要么提前释放内存要么计数越加越多资源永不释放。这正好是条款十二在资源管理类中的投影勿忘每一个成分包括那个看不见的运行时状态。当然如今这种类直接用std::shared_ptr更省心自己写引用计数属于教学代码或底层库的探索场景。4.3 移动语义下“成分”的延伸移动也要完整C11 之后移动构造和移动赋值同样存在“完整性”问题。一个常见失误class Vector { public: Vector(Vector rhs) : size_(rhs.size_) {} // 漏了 data_ Vector operator(Vector rhs) { size_ rhs.size_; // 只移动了部分成员 return *this; } private: int* data_; size_t size_; };漏掉data_导致移动后的对象处于半移动状态一部分资源被转移一部分仍是旧值。这种残缺状态在后续析构或再次使用时会产生未定义行为。移动函数同样要逐一转移每一个成员 基类部分并考虑把源对象的成员置为合法空状态保证源对象析构时不炸。所以条款十二的智慧在今天没有过时只是从“复制对象时勿忘其每一个成分”扩展成了“移动对象时也是”。5. 实操如何从根源上避免“漏成分”5.1 手写拷贝函数前的检查清单我写拷贝函数之前一定会把成员清单摆出来分三列普通成员、指针/资源成员、基类子对象。然后逐列确认普通成员是否都出现在初始化列表或赋值语句中指针/资源成员的复制程度够不够是浅复制、深复制还是按所有权语义转移基类拷贝函数是否被显式调用const成员和引用成员是否在拷贝构造初始化列表里直接初始化如果类里有虚基类还需要思考虚基类部分的复制语义。虚基类子对象通常由最派生类负责初始化拷贝构造中要显式调用虚基类的拷贝构造函数否则虚基类里那些需要参数才能初始化的状态根本不会执行。这是一个容易忽略的深层坑适合作为进阶提醒。写赋值函数时还要问一句是否处理了自赋值。x x虽然不常见但一旦存在就可能在“先释放旧资源再复制新资源”的逻辑里把源数据也释放掉后面全是脏数据。5.2 用测试和静态分析工具兜底人肉检查终究不可靠我见过太多Review时“看起来全了”上线后暴雷的例子。有效的手段主要有三个。第一一致性测试。对每个支持拷贝的类写一个“修改单成员 → 复制 → 逐成员断言相等”的测试。这个做法在加新成员时特别有用新增成员后如果忘了同步拷贝函数测试会在CI上立刻飘红逼着你补代码。时间成本不高收益非常大。第二静态分析。clang-tidy 里的cppcoreguidelines-special-member-functions、bugprone-copy-constructor-init等检查项能发现一部分拷贝函数问题cppcheck 也能发现“拷贝构造未初始化某个成员”的疑似项。但它们不是银弹遇到复杂表达式时会漏报。第三编译器 warning。-Wall -Wextra对未初始化成员会给出-Wuninitialized能提前发现一部分问题。但注意它对“拷贝函数漏掉成员”这种语义性遗漏几乎无能为力因为成员之后可能还会被赋值或默认初始化。5.3 新增成员时的“拷贝函数三连问”每当我给一个类加新成员会执行一个私人仪式问三遍这个成员支持拷贝吗如果不支持类的拷贝是删除还是改用shared_ptr如果类手写了拷贝构造初始化列表同步了吗如果类手写了拷贝赋值赋值体同步了吗如果是 copy-and-swapswap 函数同步了吗这三问实际上就是把条款十二变成了肌肉记忆。简单有效建议直接抄进自己的开发流程。6. 常见问题与排查技巧实录6.1 高频问题速查表现象可能原因排查与修复派生类拷贝后基类成员全部变成默认值派生类拷贝构造没调用Base(rhs)在初始化列表加Base(rhs)拷贝赋值后基类状态没有变化派生类operator没调用Base::operator(rhs)加Base::operator(rhs)新增成员后复制对象里永远拿不到新值拷贝函数没同步新成员按5.3的三连问逐项更新operator被调用时栈溢出或死循环赋值函数里写了*this rhs或*this Widget(rhs)改为逐成员复制或 copy-and-swap拷贝构造用了*this rhs后编译不过const/引用成员不能被赋值拷贝构造里用初始化列表不要调用赋值浅拷贝导致 double free裸指针/数组成员被默认拷贝改深拷贝或用std::string/std::vector/unique_ptr引用计数类析构时提前释放拷贝构造漏了引用计数 1拷贝构造里递增计数赋值里先减旧计数再加新计数6.2 排查思路与调试经验遇到复制类bug我的排查顺序一般是这样的。先看有没有栈溢出或崩溃转储。如果栈溢出第一反应找递归是不是operator里出现*this 或Widget(rhs)如果是 double free先看类里有没有裸指针成员然后检查拷贝构造是不是浅拷贝。如果行为只是“复制出来的对象不相等”那就好办了把源对象和副本对象的所有非静态成员在调试器里逐个对比谁不一样谁就是漏掉的成分。这个操作听起来笨但定位极快。有些IDE里可以对对象展开成员列表肉眼扫一遍就能发现。如果成员太多就写一个临时的dump_members()函数打印所有成员对比两个对象的输出。我一直觉得这种调试方式别嫌土好用就行。如果问题出在基类状态检查派生类初始化列表和赋值体有没有显式处理基类。许多新手不知道派生类拷贝赋值需要Base::operator只写了成员赋值基类部分原地不动这个坑很典型。在资源管理类里用 Valgrind 或 AddressSanitizer 跑一下double free 和 use-after-free 基本一抓一个准。现代CMake工程里加-fsanitizeaddress就能用非常推荐。我之前排查一个诡异的“复制后偶尔崩溃”问题就是在 ASan 下立刻看到use-after-free的调用栈顺着栈找到了漏掉引用计数递增的那一行。最后说点个人体会。条款十二看起来是 Effective C 里最不起眼的一条没有华丽的技巧但它逼着你回答一个非常基础的问题这个类的对象到底由哪些部分构成我写了这么多年C最大的感想是凡是能 default 就让编译器接管拷贝凡是必须手写的永远把成员清单摆在面前而不是靠记忆。版本迭代越多代码越长人脑越不可靠清单和测试才是真正的护城河。把这套思路落实下来条款十二的学费就算交成功了。
