文章详情
以下为资讯详情页模板：正文区域由后台内容渲染，图片与正文将自动替换为对应文章内容。
最近整理自己的 C 笔记正好写到继承这一块。出去面试也好带新人做项目也好我发现很多人对继承的理解停留在“子类复用父类代码”这个层面一旦问到三种继承方式的区别、虚继承的内存布局、基类析构函数为什么要加 virtual或者“隐藏和重写到底哪里不一样”现场就有点支支吾吾了。这篇文章我把笔记里关于继承的内容重新梳理了一遍加上了这几年实际写代码踩过的坑尽量把原理讲透也给出可以直接上手的写法。不管是刚学完 C 语法准备进阶的还是工作一两年想补一补基础的应该都能从中拿到点东西。1. 继承解决什么问题设计动机与使用边界1.1 没有继承时的代码困境先想一个最简单的场景你手上有一批形状类圆形、矩形、三角形都需要计算面积和周长。如果不使用继承比较原始的做法是把这些类完全独立地写出来每个类里各自实现一个getArea()。表面上看没什么问题但当你需要写一个函数统一处理所有形状时就麻烦了。比如想打印一组形状各自的面积你得写多个重载函数或者用一个switch去判断类型再往下走每加一种新形状都要往switch里塞一个分支改着改着代码就成了一坨。继承解决的核心问题是抽象统一把“都是一类东西”这件事提前到类型层面表达。通过一个基类Shape定义公共接口让所有具体形状继承它后续处理代码只需要面向Shape指针或引用编写具体是圆形还是矩形运行时才知道这就为多态创造了条件。这里建议把两种复用分开理解。接口继承主要目的是统一调用方式基类里放纯虚函数强调“子类必须能做什么”实现继承主要目的是复用代码基类里放具体成员函数和成员变量强调的是“子类可以直接用什么”。这两个方向常常混在一起但设计时要时刻想着哪个才是主要目的。如果一个类你只是想省几行重复代码而去继承它那十有八九应该用组合而不是继承。1.2 该用和不该用继承的边界工作里有个比较朴素的判断标准问自己“子类是不是基类的一种”而不是“子类需不需要基类的某些功能”。企鹅是一种鸟鸟会飞但企鹅不会飞用继承硬做就会很尴尬。反过来如果你只是想在一个已有的Logger类里加一个写数据库的方法正确做法往往是包含一个Logger成员而不是class DbLogger : public Logger。继承也容易把层次结构写深。三层以内的继承关系人眼还能看明白一旦超过四五层某个方法到底是哪个中间层重写的排查起来非常痛苦。我见过有人为了复用两个方法把继承链拉到六层最后新需求一来发现改最顶层影响到了所有子类根本不敢动。所以我的建议是能用组合表达的关系优先组合只有“is-a”关系非常自然、并且确实需要多态接口时才用继承。这个思路不是否定继承而是提醒继承要克制地使用。C 里组合和继承都在语言层面得到了很好的支持好钢要用在刀刃上后面讲多继承的部分还会看到滥用继承会带来更大的麻烦。2. 继承语法与访问规则拆解2.1 三种继承方式权限变化的底层逻辑C 的关键字public、protected、private同时也是继承方式的关键字。很多教材上只会给一张权限表然后让背这里我从“谁来访问”这个角度重新解释一下理解之后不需要硬记。先说访问级别的本质public成员谁都能碰protected成员自己和子类能碰、外部碰不了private成员只有自己内部能碰。那么当你用一个继承方式去继承基类时实际上做的事情就是给基类成员的访问权限“打折”public继承权限不变protected继承把基类的public成员降级成protectedprivate继承则把基类的所有成员都在派生类里变成private。注意一个容易忽略的点基类的private成员无论你用哪种方式继承派生类都无法直接访问继承方式影响的是那些原本可见的成员即基类的public和protected成员。用一个实际例子来说明。你要写一个Base基类里面有三个成员函数分别对应三种访问级别然后用三种方式分别派生三个类。代码写法上差别不大关键差异体现在“这个派生类继续被继承”或“外部访问”时class Base { public: void pubFunc() {} protected: void protFunc() {} private: void privFunc() {} }; class PubDerived : public Base { // pubFunc 仍是 public // protFunc 仍是 protected }; class ProtDerived : protected Base { // pubFunc 降级为 protected // protFunc 仍是 protected }; class PrivDerived : private Base { // pubFunc 降级为 private // protFunc 降级为 private };实际工程里 95% 以上你只会见到public继承因为只有它维护了完整的“is-a”关系protected和private继承更像是实现继承表达的是“is-implemented-in-terms-of”也就是拿基类内部的实现来服务派生类但对外完全不暴露继承关系。如果你遇到有人用private继承通常他想表达的是我不想让外部把Derived当作Base来用但我又需要复用Base的某些能力。这种场景下用“组合一个 Base 成员”基本能替代只是在极少数需要访问protected成员或重写虚函数时private继承才更有优势。2.2 构造与析构顺序对象生命周期的完整链路继承之后派生类对象的构造不是“只构造派生类自己”那么简单。C 有明确规则构造时先构造基类部分按基类声明顺序再构造派生类自己的成员按成员声明顺序最后执行派生类构造函数体。析构时顺序完全相反先执行派生类析构函数体再析构派生类成员最后析构基类部分。这个顺序其实蕴含了一条重要设计原则构造时基类先就绪派生类才能在构造函数体里放心使用基类提供的资源析构时派生类先清理基类再收尾避免派生类资源还在使用时基类就把底层资源释放了。写代码时要注意初始化列表的书写顺序。C 要求初始化列表的顺序必须和成员声明顺序一致否则编译器会警告而且实际初始化顺序还是按声明顺序来。继承场景下基类构造函数的调用也是通过初始化列表完成的形式是在冒号后面写上基类类名和参数。比如class Base { public: Base(int x) : value_(x) {} private: int value_; }; class Derived : public Base { public: Derived(int x, int y) : Base(x), extra_(y) {} private: int extra_; };如果不写Base(x)编译器会尝试调用Base的无参构造函数如果基类没有无参构造函数代码直接编译报错。这一点在写带参构造的基类时要特别注意。再有就是基类构造和析构期间调用虚函数是不会多态派发的。这个坑很隐蔽基类构造函数执行时派生类部分还未初始化所以即使虚函数指向派生类版本运行时也不会调用它而是老老实实调用基类自己的版本。如果你在基类构造函数里调了一个虚函数指望派生类重写后的行为生效结果往往会出乎意料这在项目里很容易变成疑难 bug。析构顺序还有一个和堆内存相关的经典问题基类析构函数如果不是虚函数通过基类指针delete派生类对象就是未定义行为。典型的症状是派生类析构函数没被调用资源泄漏严重时直接崩溃。更安全的习惯是一旦类里面有虚函数或者这个类注定要当基类就把析构函数写成virtual这个我们后面专门展开。2.3 隐藏、重写与重载三个容易混淆的概念这三个概念面试几乎是必考的而且工作里写错了编译器也不会报错行为却完全不对。重载overload同一个作用域内函数名相同、参数列表不同的多个函数。注意必须是同一作用域所以基类和派生类之间的同名函数不算重载。隐藏hide派生类中定义了一个和基类同名的函数不管参数是否相同基类版本在派生类作用域内会被隐藏。隐藏的关键点是即使你调用时参数完全匹配基类版本编译器也不会去基类里找因为名字查找在解析参数前就停止了。重写override派生类重新实现基类的虚函数函数签名必须和基类版本一致返回值有协变等特殊规则并且函数在基类中声明为virtual。隐藏很容易踩坑因为它会带来“我明明调的是基类接口为什么跑的是派生类逻辑”或者相反的感觉。看个例子class Base { public: void Print() { cout Base endl; } virtual void Draw() { cout Base Draw endl; } }; class Derived : public Base { public: void Print() { cout Derived endl; } // 隐藏 void Draw() override { cout Derived Draw endl; } // 重写 };Base指针指向Derived对象的时候p-Print()调用的是基类Print因为Print不是虚函数静态绑定p-Draw()调用的是派生类Draw因为Draw是虚函数动态绑定。如果两个同名函数的区别搞不清楚写出来的行为会非常迷惑。“隐藏”这个特性本来是 C 为了保证名称查找安全而设的规则但它经常给新手带来麻烦。如果你想在派生类里使用被隐藏的基类版本需要显式用基类名::函数名(...)来调用比如Base::Print()。另外有个好习惯在派生类重写虚函数时加上override关键字这样一旦签名和基类不一致比如参数类型差了一个 const编译器会直接报错而不是默默生成一个隐藏版本导致你在多态调用时发现子类逻辑没有生效。3. 多继承与菱形继承C 的复杂三角关系3.1 多继承的使用场景与争议多继承是从 C 诞生起就充满争议的话题。Java、C# 等语言干脆单继承加接口而 C 允许一个派生类同时继承多个基类。支持者说它更灵活反对者说它让对象模型变得复杂。实际工程中多继承确实有它的用武之地但用不好就会制造灾难。最正面的使用场景是mix-in一些不构成“主身份”的辅助能力比如Printable、Serializable、FileOwner它们各自提供一组操作接口一个类可以根据需要“混入”多个能力。这比用一层层单继承表达“身兼数职”要干净很多因为那些辅助能力之间没有层级关系强行把它们排成一条继承链纯属给自己找麻烦。多继承最著名的坑是菱形继承也就是 B 和 C 都继承 AD 同时继承 B 和 C。这种情况下的存储布局中A 的部分会被复制两份D 对象里实际存在两个 A 子对象。当你写d.A::func()时编译器会迷茫到底哪个 A结果就是二义性编译错误或者你不得不使用B::func()、C::func()这样别扭的限定方式来消除歧义。菱形继承还带来了重复初始化的风险。最经典的场景是A里有一个文件句柄资源B和C构造时都会打开或复制一份而D想让这个句柄全局只有一份结果对象里出现了两份层次结构越深越难控制语义。3.2 虚继承的解决原理与内存布局解决菱形继承的方法是虚继承virtual inheritance。声明方式是在继承列表中加上virtual关键字class A { public: int value; }; class B : virtual public A {}; class C : virtual public A {}; class D : public B, public C {};虚继承会把 A 子对象变成共享的唯一实例。此时D的内存布局大致由两部分构成B和C各自的数据区域以及一个被共享的A子对象。B 和 C 中不再直接内嵌完整的 A 数据而是保存一个指向共享 A 子对象的指针常见实现是虚基类表vbtable 偏移量。这样在D中通过B或C访问 A 的成员时实际上都指向同一个对象区域。这个设计解决了一致性问题但它不是免费的。虚继承需要额外的指针或偏移查找性能上有少量损耗对象布局也不再是简单连续排列调试时看内存布局要花更多时间。更重要的是构造规则变复杂了虚基类 A 的构造函数由最派生类负责调用而不是由直接继承它的 B、C 调用。也就是说你在写D的构造函数时要在初始化列表里直接写A(...)哪怕 D 不是 A 的直接派生类。如果你忘了写A 会尝试调用默认构造没有默认构造就报错。这个规则很容易让人措手不及。还有一点要注意虚继承的初始化顺序是先虚基类然后按继承顺序构造普通基类。如果B和C的构造函数里都想要给某个继承自 A 的成员设置初值这些赋值最后都会被最派生类 D 构造流程中的 A 构造覆盖或影响所以代码里要约定清楚A 的初始化只能由 D 负责B、C 的构造函数里不要再重复初始化 A 的成员否则会出现值被覆盖的诡异现象。尽管虚继承解决了菱形问题我还是建议在业务代码里优先用组合替代深层的多继承关系。遇到“D 同时继承 B 和 C而 B、C 又继承同一个 A”这种结构时先停下来想一想这个 A 是不是真需要共享把 A 作为 D 的成员而不是通过两路继承进来说不定更直接。4. 继承与多态、关键字细节联动4.1 虚函数与 override/final现代 C 的安全护栏继承和多态能如此紧密地绑定在一起核心机制就是虚函数。编译器在对象中插入一个虚表指针vptr指向类的虚函数表vtablevtable 里存放每个虚函数对应的函数指针。当通过基类指针或引用调用虚函数时运行时先找到对象的 vptr再查表得到真实对象的函数地址这个查表过程就是动态绑定。因为有这层间接才实现了“同一段调用代码面对不同子类对象表现不同行为”的效果。但动态绑定也有代价一次间接调用不能内联大多数情况下而且每个带虚函数的对象都要多占用一个指针大小的空间。对性能极致敏感的场景比如某些游戏引擎的热点路径会刻意减少虚函数的使用改用模板或者手工 dispatch。一般业务代码完全不用在意这种开销辩证看待就好。现代 C 给虚函数加了两道安全护栏分别是override和final。override明确告诉编译器“这是重写基类的虚函数”如果基类没有匹配的虚函数编译直接失败这能帮你提前发现签名写错、基类函数被改名这类低级错误。final声明在虚函数或类上表示“到此为止不许再重写/继承”。它能阻止别人无意中扩展你的核心逻辑也能给编译器更多优化空间因为final类的虚调用可以退化为直接调用。我见过很多团队在接口类上不加final结果后人为了扩展一个方法层层继承最后接口完全失控这种场景下final是一个很好的设计约束工具。这里补一句容易被忽略的虚函数的默认参数是静态绑定的。也就是说即便调用的是派生类的重写版本如果通过基类指针调用默认参数依然是基类里写的那个值。这个行为极其容易制造 bug。例如基类虚函数virtual void Draw(bool smooth true);派生类重写时写了bool smooth false你用基类指针调用时传不传参都会走true代码看起来逻辑没问题实际跑出来完全是另一回事。建议的做法是默认参数只写在基类接口处派生类重写时不要写默认参数。4.2 static 与 const 在继承中的行为差异继承体系下static和const的行为常常被人忽略但它们在实际项目中引发的 bug 也不少。static 成员在继承中的行为类中的static成员属于类本身不属于任何对象。派生类继承基类时static成员并不会被“复制”一份整个继承体系共享同一个static变量。你在派生类里写Base::count和Derived::count其实访问的是同一个实体。这种行为有时是想要的比如统计整个继承体系创建了多少对象有时却是个坑比如你希望每个派生类各自维持一个独立计数器那就不能直接继承static成员得换成模板技巧或每个派生类单独定义。static 成员函数也是类似的它和对象无关没有this指针。所以在继承中static成员函数不能是虚函数不能被重写只能被隐藏。调用Derived::staticFunc()和Base::staticFunc()如果两个类都定义了同名 static 函数实际上是通过名字查找选中的不同函数不存在多态派发。千万不能在设计接口时指望 static 函数做动态绑定语言层面就不支持。const 成员函数与继承const修饰的是成员函数内部不能修改对象的非静态成员mutable 除外。在继承场景中重写一个虚函数时const限定符必须严格一致。基类里是virtual void Func() const派生类里写void Func()编译器不会认为这是重写而会当成隐藏因为函数签名不同就算你加了override编译也直接报错。实际项目里最常见的错误就是基类接口给函数加了const派生类实现时少了const结果运行时多态完全不生效。遇到这种问题别上来就怀疑虚表先逐个检查签名。还有一个和const相关的常见设计误区在派生类重写时如果需要修改某些成员但又必须保留基类接口的const语义比较稳妥的做法是使用mutable修饰那些需要惰性计算或缓存的成员而不是去掉const。比如一个接口的GetSize() const里要计算缓存结果就可以把cacheValid和cachedSize声明为mutable这样既符合接口语义又能实现可变的内部状态。4.3 基类析构函数为什么必须是 virtual这是我面试新人时几乎必问的问题。很多人知道“要加 virtual”但说不清原理。这里补一次完整的推理链。考虑这种情况Base* p new Derived(); delete p;delete一个基类指针时编译器需要确定调用哪个析构函数。如果基类析构不是虚函数这里就是静态绑定——它调用的是Base::~Base()而不是Derived::~Derived()。后果分两步先执行 Derived 的析构函数体这一步被跳过再析构 Derived 的成员对象这一步也被跳过最后只执行了 Base 的析构函数。如果 Derived 持有堆内存、文件句柄、互斥锁等资源全部泄漏。更糟的是析构后的对象状态不完整某些平台下再次释放或清理时还可能崩溃产生类似 access violation 的随机崩溃。解决办法就是让基类析构函数成为虚函数。这样delete p会先查虚表找到真实对象对应的析构函数调用Derived::~Derived()析构完成后自动按“先派生后基类”的顺序调用基类析构整条资源释放链路就完整了。选择上有个细节如果这个类注定要当基类哪怕目前只有一个虚函数也建议把析构写成虚的。但注意一个反方向的经验如果这个类不会被继承不要无脑给每个类都加虚析构因为每个对象要多占一个 vptr而且失去了内联优化机会。在性能敏感的地方你可能会把析构设为protected来阻止外部delete这也算一种被很多人忽略的替代方案不过日常写业务代码还是老老实实加virtual更稳妥。5. 实操中常见的坑与排查实录5.1 对象切片把派生类赋值给基类时发生了什么对象切片是 C 特有、而且特别容易踩的坑。当用派生类对象直接给基类对象赋值时比如Derived d; Base b d; // 切片b得到的是d的基类子对象副本所有派生类特有的成员变量和虚函数相关信息全部丢失。如果你以为b还在以某种方式保留着Derived的行为那必然出事。原因也很直白Base对象的存储大小是固定的装不下Derived的全部内容编译器只能把属于Base的那一段拷贝过去。要避免切片最简单的规则是传递对象时尽量用指针或引用不要用值传递。函数参数写const Base返回值用指针或智能指针容器里存放指针而不是对象。如果确实需要复制一个完整的多态对象正确做法是给基类加一个虚的clone()函数由每个派生类返回自己类型的新对象这算是原型模式的典型应用。切片问题在 STL 容器里尤其阴险。写下vectorBase v; v.push_back(d);时插入的瞬间切片就发生了容器里存的都是“被阉割”的基类对象你后面想让它表现派生类的行为纯属想多了。正确的容器类型应该是vectorunique_ptrBase或vectorshared_ptrBase。还有一个没这么常见但值得警惕的在基类构造函数中调用虚函数即使这段代码编译通过、运行不报错你得到的行为也往往是基类版本的而不是派生类的。这在前面提到过算是切片的一种时间维度变体——对象还没完全构造好多态能力是不完整的。5.2 基类指针访问派生类特有接口向下转型的规范姿势有时候你有基类指针但确实需要调用派生类特有的接口。这里最常见的错误是用 C 风格强转或者static_cast硬转然后直接调用如果对象根本不是这个类型结果就是未定义行为通常表现为访问了错误的内存调用了一个不存在的函数轻则返回垃圾数据重则崩溃报access violation。正确的做法是使用dynamic_castDerived* pd dynamic_castDerived*(pb); if (pd) { pd-OnlyDerivedMethod(); }dynamic_cast会做运行时类型检查如果pb指向的对象确实是Derived类型或它的子类返回有效指针否则返回nullptr。这是安全的向下转型但要求两个条件基类必须有虚函数这样才有运行时类型信息并且一般要求是 public 继承。注意dynamic_cast有运行时开销因为它要查 RTTI在性能敏感的循环里要避免频繁使用。如果运行 RTTI 被关闭比如某些嵌入式编译环境里禁用 RTTI 以节省空间dynamic_cast不可用这时可以退而求其次在基类里设计虚函数接口把需要区分行为的操作统一表达出来或者用static_cast加上自己的类型标识字段来判断但后者不如虚函数机制优雅也有维护成本。实践中更推荐的做法是尽量用虚函数接口表达不同行为减少向下转型的次数转型只用于真正无法用多态表达的场景比如需要调用特殊能力且这种能力不适合做公共接口时。5.3 继承体系下的典型问题排查表下面这些问题是实际排查中反复遇到的我整理成一个速查表方便你在现场快速定位现象可能原因排查思路基类指针调用派生类重写函数没生效函数不是虚函数签名不一致导致成为隐藏加 override检查 const/参数类型是否严格一致delete 基类指针后内存泄漏基类析构函数不是 virtual补 virtual 析构派生类构造时崩溃或成员值异常基类没有无参构造而初始化列表又没调用带参基类构造检查初始化列表是否显式传参给基类构造期间虚函数行为不符合预期基类构造阶段虚函数不派发不要在构造析构函数中调用虚函数主体逻辑菱形继承中访问基类成员出现二义性非虚继承A 子对象存两份改为 virtual 继承或改组合数组或容器中多态失效对象切片用指针存放或用虚 clone()编译报错“cannot cast...”dynamic_cast 使用不当或基类无虚函数确认基类有虚函数且目标类型可转换排查有一个通用步骤先确认虚函数签名是不是完全匹配再确认调用对象的生命周期避免基类指针指向已析构对象接着看内存布局确认对象是不是发生了切片。这三步能解决绝大多数继承相关的诡异问题。5.4 实战动态创建派生类对象时的一个隐蔽崩溃最后分享一个我之前项目中真实遇到过的崩溃对理解继承场景很有帮助。当时有一个基类Plugin派生类AudioPlugin插件对象由工厂函数返回工厂里写的是Plugin* createPlugin() { Plugin* p new AudioPlugin(); return p; }调用方在结束时执行Plugin* p createPlugin(); // ... 使用 ... delete p;这段代码看起来没有异常第一次运行时也没有崩溃但压力测试下析构函数调用链里开始出现偶发的堆错误。排查到最后才发现Plugin析构函数没有写成虚函数delete p只析构了基类部分AudioPlugin内部的缓冲区指针没有被释放随着多次创建销毁堆被反复写入垃圾数据最终崩溃。这个 case 背后其实并不难但它的隐蔽性在于不是每次 delete 都立刻崩而是内存压力到一定程度才开始出错错误报出来时往往离源头已经很远。修复也极其简单把基类析构函数加上virtual问题消失。这个经验我在别的项目里也反复遇到过写完这个笔记之后我给自己定了一条硬规矩凡是设计给别人当基类的类第一件事就是写一个virtual ~类名()空实现即使现在没有任何需要清理的资源也先写上因为等以后其他人继承扩展时这条保障会变成无形的保护网。继承是 C 里面最“具有设计感”的语言特性它把类型之间的关系直接暴露在代码结构里。用好了代码的表达力和维护性都会有很大提升用不好就会陷入脆弱的层级设计里反复修补。希望这份笔记能帮你在写继承代码时更清楚自己在做什么也能在面试或者排查问题时多几分底气。特别提醒：考试时间、报名批次等安排如有调整，以河南省应急管理厅及官方考点最新通知为准。
