1. 这份笔记的缘起继承不是拿来用这么简单刚接触 C 时我对继承和多态的理解非常粗浅——子类继承父类的成员和方法虚函数能实现多态仅此而已。真正开始写工程代码后才发现从菱形继承到虚表机制每一个话题背后都藏着教材里不写的问题访问权限怎么收放、什么时候需要 virtual、为什么有人宁愿用组合也不用继承。这篇文章不打算写成教科书式的定义罗列而是把我自己从会用到理解这个过程里值得记录的笔记按继承的几种方式 → 菱形继承 → 虚表机制 → 实战坑点这条线完整过一遍。我假设读这篇笔记的你已经知道类、对象、成员函数这些基本概念但对继承和多态可能停留在知道关键字不清楚背后发生了什么的阶段。走完这条线之后你会知道为什么说 C 的继承和多态核心不在语法而在内存布局和类型语义。1.1 继承真正的价值类型关系不只是代码复用继承的第一个直观作用是代码复用但这不是继承的全部价值甚至不是主要价值。继承真正带来的东西是类型关系派生类是一种基类因此可以出现在任何需要基类的位置这为多态提供了前提。可以把继承理解为一种类型契约——子类承诺自己具备父类的对外能力同时可以改写其中一部分能力的具体实现。这里先给出一条贯穿全文的判断标准当你用继承时请时刻问自己我依赖的是父类的数据成员还是父类的行为接口如果是前者通常用组合更安全如果是后者继承才真正发挥它的意义。这个判断标准后面每个章节都会用到。提示如果你只是想复用某个类的实现代码优先考虑组合成员对象而不是继承。继承是类型关系的表达不是代码复用的工具。这条经验帮我少写了很多为了少敲几行字而引入继承的烂代码。为了让后面的讨论有共同基础下面用一个具体的类层次作为全篇的贯穿例子class Animal { public: Animal(const std::string name) : name_(name) {} virtual std::string sound() const { return ...; } const std::string name() const { return name_; } virtual ~Animal() default; protected: std::string name_; }; class Dog : public Animal { public: Dog(const std::string name) : Animal(name) {} std::string sound() const override { return Woof; } };这个例子包含两个马上要用到的核心点Dog通过public继承Animalsound()是虚函数。第二章先把目光放在继承方式上。2. 三种继承方式public、protected、private 各自的可见性账本2.1 一张表看懂访问级别在继承时的传递规则继承方式决定父类成员在子类里的最终访问级别。这个规则可以用一句话概括子类中成员的最终访问级别等于 min(成员自身访问级别, 继承方式)。注意这里说的是父类成员在子类中的可见性不是父类自身的封装性。父类成员public继承后在子类中protected继承后在子类中private继承后在子类中public 成员publicprotectedprivateprotected 成员protectedprotectedprivateprivate 成员不可直接访问不可直接访问不可直接访问重点在于private 成员在任何继承方式下都无法被子类直接访问只能通过父类提供的公有或保护接口间接访问。这其实是封装性的一个重要体现——继承不会破坏父类数据成员的私有边界。很多初学者以为继承就是子类能用父类的所有成员这个理解从一开始就是错的。这个规则有一个经常被忽略的灰区在子类中无论采用哪种继承方式父类的 protected 成员都是可以访问的区别只在于子类之外能否把子类对象当成父类对象使用。也正是这个原因我在实际工作中很少使用 protected 继承和 private 继承但理解它们依然有价值——你读别人代码时会遇到也可能在底层库的实现里看到这类技巧。2.2 public 继承唯一的is-a继承public 继承表达的是严格的 is-a 关系一个 Dog 就是一个 Animal。这意味着子类对象可以在任何需要父类引用的地方直接使用编译器会做隐式转换void print_sound(const Animal a) { std::cout a.name() : a.sound() std::endl; } Dog d(Rex); print_sound(d); // 子类对象当父类引用用ok之所以能这样写根本原因是 Dog 对象的内存布局里从起始地址开始就完整包含了一个 Animal 子对象。后面讲虚表的时候还会回到这个布局问题上。工程上 99% 的继承都应该是 public 继承。C 社区里有个广为人知的说法如果一段代码需要用 protected 或 private 继承请仔细检查它是否真的应该用继承。多数情况下它应该是一个成员对象。public 继承还意味着一个隐含承诺子类可以在任何基类适用的场景下无缝替换基类这就是里氏替换原则在语言层面的体现。一旦某个派生类在实际行为上违背了父类的约定例如父类保证不会抛异常子类却可能抛继承关系的合理性就需要重新审视。2.3 protected 与 private 继承被低估的实现继承手段protected 继承和 private 继承表达的不是 is-a而是is-implemented-in-terms-of用某类来实现自己。它们允许你重用父类的实现但对外不暴露父类的类型身份。举个例子假设我要实现一个Stack类内部想复用std::vector的存储能力但不想让外部代码把Stack当成vector使用更不能直接调用 vector 的任意方法。用 private 继承是一个合法方案class Stack : private std::vectorint { public: using std::vectorint::push_back; using std::vectorint::pop_back; using std::vectorint::back; bool empty() const { return std::vectorint::empty(); } };注意到我用using把选中的接口重新提升为 public。这种对继承来的接口做选择性暴露的做法是 private 继承最有价值的使用场景。不过说实话在现代 C 里我更推荐直接用成员对象加转发函数因为继承还会带来构造函数、赋值运算符等一系列初始化顺序问题纯实现复用用组合更省心。protected 继承则更少见它表达的是允许子类及子类的子类访问但对外隐藏父类身份。在某些框架代码里基类把一组需要传递给更下层类的成员用 protected 继承包一层算是这类继承为数不多的合理用途。3. 菱形继承继承体系里的回字形陷阱3.1 什么是菱形继承它为什么会出错当两个派生类继承同一个基类而一个更下层的类又同时继承这两个派生类时类层次结构就会形成一个菱形。用我上面动物类的思路扩展一下假设有个FlyingAnimal和一个SwimmingAnimal它们都继承自Animal然后Duck同时继承两者。这就是经典的菱形class FlyingAnimal : public Animal { /* ... */ }; class SwimmingAnimal : public Animal { /* ... */ }; class Duck : public FlyingAnimal, public SwimmingAnimal { /* ... */ };问题随之而来Duck 对象里会包含两份Animal子对象一份来自FlyingAnimal一份来自SwimmingAnimal。访问name_时会因为存在两份数据而产生二义性编译器会直接报错。这份冗余不仅浪费内存更重要的是破坏了 is-a 语义——一个 Duck 应该是一个 Animal而不是两个 Animal。动手写一下会更直观。如果你在代码里写d.name()编译器不知道你要访问的是 FlyingAnimal 路径上的 Animal还是 SwimmingAnimal 路径上的 Animal于是抛出一个 ambiguous 错误。解决方式之一是显式指明路径d.FlyingAnimal::name()。但这样做既繁琐又违背直觉一个鸭子不该拥有两份名字数据。更隐蔽的问题在于第二次继承时基类被重复构造两路继承都会各自调用 Animal 的构造函数如果 Animal 内部有计数、连接等有状态资源双份状态直接就会造成逻辑矛盾。3.2 virtual 继承让中间层共享同一个祖先解决方法是把共同祖先声明为 virtual 基类class FlyingAnimal : public virtual Animal { /* ... */ }; class SwimmingAnimal : public virtual Animal { /* ... */ }; class Duck : public FlyingAnimal, public SwimmingAnimal { /* ... */ };virtual修饰的是到 Animal 的这条继承路径它告诉编译器最终派生类中只需要一份 Animal 子对象所有虚继承它的派生类共享这一份。这样d.name()不会再有二义性也消除了数据冗余。需要特别说明的是 virtual 继承带来的构造顺序变化。C 规定virtual 基类由最底层的派生类负责初始化且先于非 virtual 基类构造。也就是说构造 Duck 时不是由FlyingAnimal或SwimmingAnimal来初始化Animal部分而是 Duck 的构造函数必须显式调用Animal的构造函数class Duck : public FlyingAnimal, public SwimmingAnimal { public: Duck(const std::string name) : Animal(name), // 最底层派生类负责虚基类初始化 FlyingAnimal(name), SwimmingAnimal(name) {} };如果漏掉Animal(name)就只能调用 Animal 的默认构造。这一点在重构时尤其容易踩坑——当你把一个普通继承改成虚继承后所有中间层的构造函数签名都可能需要跟着调整。虚继承的底层实现通常是让每个虚基类子对象通过额外的偏移表或指针间接访问因此运行时访问虚基类成员会比普通成员多一层间接跳转这是它的性能代价。3.3 菱形继承在工程里的真实处境说实话现代 C 工程里菱形继承很少出现很多人甚至把虚继承称为语言的暗角。我自己只在接口类纯虚类的多重继承场景里偶尔见到比如同时继承多个纯抽象接口而这些接口又共同继承了一个纯虚基类。虚继承的主要成本是运行时访问虚基类成员通常需要多一层间接跳转性能上有轻微影响而且内存布局更复杂。注意如果遇到菱形继承先别急着加 virtual想想结构是不是可以改成组合。把公共部分作为成员对象让上下层通过包含关系而不是继承关系组织往往更清晰也更符合组合优先于继承的原则。虚继承还有一个隐蔽的坑它改变了对象的构造顺序。这个顺序不是按继承声明顺序而是按虚基类最优先、然后深度优先、再按声明顺序的规则。如果一个大工程里有人在不同层级插入虚继承对象的构造顺序会变得很难直观判断调试时非常头疼。所以我的态度是菱形继承最好只出现在纯接口的汇聚处任何带数据成员的虚基类都意味着复杂度和风险。4. 虚表与虚指针多态背后隐藏的内存真相4.1 有了虚函数一份类就多了一张函数地址表多态的实现并不复杂核心是类对象内部多了一个隐藏的指针指向一张属于该类的虚表。虚表本质是一个数组里面按声明顺序存放该类每个虚函数的地址。只要类里有虚函数或虚析构函数、重写的虚函数对象开头就会有一个vptr虚指针。可以这样理解虚表就像一本菜单vptr 就是客人手里的那本菜单。第一行永远是招牌菜第一个虚函数第二行、第三行依次排列。编译器在调用虚函数时不直接写死函数地址而是先翻菜单根据对象手里的菜单版本找到对应的实现。以下面这段为例class Animal { public: virtual std::string sound() const { return ...; } virtual ~Animal() default; }; class Dog : public Animal { public: std::string sound() const override { return Woof; } };Animal对象里有vptr指向Animal的虚表Dog对象里也有自己的vptr指向Dog的虚表。两张虚表里sound()的槽位一样但存放的地址不同——Dog 表里存放的是Dog::sound()的地址。调用animal.sound()时编译器不是直接生成调用 Animal::sound的指令而是生成通过对象的 vptr 找到虚表再从正确槽位取出函数地址来调用的指令。同一份调用代码因为对象实际类型不同走不同的函数地址这就是多态。需要注意的是虚表本身按类生成同一个类的所有对象共享同一张虚表。每个对象只多一个 vptr这就是虚函数带来的内存成本。如果一个类没有虚函数对象大小就是成员变量的总和一旦加了第一个虚函数对象立刻就多出一个指针的大小64 位平台上通常是 8 字节。在很多性能敏感的场景里这个开销也要纳入考虑。4.2 覆盖与隐藏两个长得像、实际完全不同的概念很多初学者会把重写虚函数和在子类定义同名函数混为一谈这两件事机制完全不同。重写override是覆盖虚表里对应的函数地址函数必须满足三个条件基类函数是虚函数、子类函数签名完全一致、子类函数也声明为 virtual现代 C 推荐用override关键字让编译器替你检查。隐藏hide则只是子类定义了与基类同名的函数基类的那个函数会被盖住调用时如果不加作用域限定符匹配到的是子类版本但它不参与多态。我写过一个很典型的隐藏导致的 bugclass Base { public: virtual void show() { std::cout Base\n; } }; class Derived : public Base { public: void show(int x) { std::cout Derived: x \n; } // 隐藏了 Base::show() }; // 调用 Derived d; Base b d; b.show(); // 输出? 这里才是多态调用没问题 // d.show(); // 编译错误子类中 show(int) 隐藏了无参版本加了一个重载后子类的show(int)把基类里的show()隐藏掉了导致通过子类对象直接调用无参 show 会编译失败。解决方式是用using Base::show;把基类版本引入子类作用域。这类问题在重载虚函数时特别容易遇到记住一个经验子类尽量不要改动虚函数的重载集合要么不加重载要么用 using 把基类版本全带进来。另外写override还有一个额外好处它能帮编译器抓住签名不一致的问题。比如基类是virtual void sound() const你在子类里写成void sound()少了 const编译器认为这是隐藏而不是重写。如果不加override一切照常编译多态悄悄失效加了之后编译器会直接报错。这种让错误在编译期暴露的机制是 C 现代风格里非常值得养成的好习惯。4.3 对象切片多态失效的一个高发场景虚表机制成立的前提是通过引用或指针调用虚函数。一旦把派生类对象按值赋给基类变量就会发生对象切片——派生类中多出来的部分被丢弃基类子对象被拷贝过来vptr 也被更新为基类的。切片之后多态不复存在。Dog d(Rex); Animal a d; // 切片只有 Animal 部分被拷贝 std::cout a.sound(); // 输出 ..., 不是 Woof切片是 C 里让新手最困惑的多态失效现象。理解了虚指针属于对象整体内存布局的一部分之后这个现象就顺理成章了。切片后对象已经变成 Animal它的 vptr 自然指向 Animal 的虚表。所以规则很简单传递多态对象请用引用或指针按值传递就是和虚表机制说再见。切片还有一个更隐蔽的表现它会导致资源管理混乱。如果子类持有智能指针或原始指针成员按值拷贝时如果没有正确实现拷贝语义就会出现双重释放或悬空指针。写容器时如果错误地把派生类对象塞进std::vectorAnimal实际上容器里存的是一堆被切片的 Animal所有子类行为全部丢失。正确的做法是容器存std::shared_ptrAnimal或std::unique_ptrAnimal让对象生命周期和类型信息都完整保留。5. 多态与继承实战中最容易踩的坑5.1 构造函数里调用虚函数调用的是当前正在构造的那个版本构造函数执行期间对象的动态类型被认为是当前正在构造的类。所以在基类构造函数里调用虚函数不会触发子类重写版本而是调用基类版本。因为构造子类对象时是先从基类部分开始构造的此时子类部分还没成型vptr 还指向基类的虚表。class Base { public: Base() { print(); } // 输出 Base virtual void print() { std::cout Base\n; } }; class Derived : public Base { public: Derived() { print(); } // 输出 Derived void print() override { std::cout Derived\n; } }; Derived d; // 输出顺序: Base 然后 Derived这个现象的背后逻辑很容易理解vptr 是随着构造进展而更新的。Base 的构造函数运行时对象还只是一个完整 Basevptr 指向 Base 的虚表进入 Derived 构造函数后vptr 才切换成 Derived 的虚表。把它看作构造过程就是 vptr 的逐步升级过程就不会再对这种调用结果感到意外。工程中的正确姿势不要在构造函数里调用虚函数来完成看起来会根据子类类型走多态的初始化逻辑。如果确实需要用两段式初始化或者把公共逻辑放到底层构造完成之后再触发的接口里。析构函数同理——析构时 vptr 又会逐级降回基类版本析构顺序决定了虚调用只会落在当前正在析构的类上。5.2 析构函数为什么必须是虚的delete 基类指针时的接管问题当通过基类指针 delete 一个派生类对象时如果基类析构函数不是 virtual行为是未定义的。实际表现通常很直接只执行了基类的析构派生类部分申请的资源没有释放。这就是析构函数需要声明为 virtual 的核心原因——delete 一个指向派生类的基类指针本质也是一种虚调用。C11 之后建议这样写class Animal { public: virtual ~Animal() default; };凡是准备作为多态基类使用的类析构函数都应该是 public virtual 或 protected 非 virtual。如果类不打算被继承析构函数不需要 virtual加上去反而会让对象多一个虚指针白白增加内存占用。判断标准很简单这个类有没有虚函数如果有几乎一定会有通过基类指针释放子类对象的用法那就必须让析构函数 virtual。还有一个容易忽略的点即使你从不手动 delete当基类对象持有了某个派生类对象的 unique_ptr 时unique_ptr 的删除器默认会调用基类析构如果基类析构不是虚的懒删除会引发未定义行为。这类问题往往在压力测试或内存检测工具下才会暴露查起来代价很高。5.3 dynamic_cast 与 RTTI多态类型转换的兜底手段多态可以将派生类对象当基类使用但有时候需要反方向转换——把基类引用或指针还原成真正的派生类。dynamic_cast可以在运行时检查转换是否安全void speak(const Animal a) { const Dog* dog dynamic_castconst Dog*(a); if (dog) { std::cout Its a dog: dog-sound() \n; } }dynamic_cast 依赖 RTTI运行时类型信息要求类层次里有虚函数。如果转换失败指针版本返回 nullptr引用版本抛出std::bad_cast。使用动态转换通常意味着设计上存在让步——如果你发现自己频繁用 dynamic_cast 去判断这个对象到底是哪个子类大概率是接口设计得不够充分应优先考虑把不同行为抽象成虚函数。我见过一个极端案例项目里有个函数接收基类引用然后连续用五六个 dynamic_cast 去尝试转成不同子类每个都判断空指针。这段代码一出现新子类就要改几乎是维护噩梦。更好的做法是给基类加一个虚函数把到底该做什么下放到子类决定。dynamic_cast 在极少数场景下确实是必要的比如跨模块类型检查、序列化模块读取等但它不该成为日常设计中处理分支的主力工具。5.4 多重继承与接口组合什么时候可以放心用多重继承本身不是洪水猛兽真正危险的是多个带数据成员的基类。如果多重继承里所有基类都是纯虚接口没有数据成员那么它非常安全也很有用。C 里没有独立的 interface 关键字纯虚类就是最接近接口的东西。class Drawable { public: virtual void draw() const 0; virtual ~Drawable() default; }; class Clickable { public: virtual void onClick() 0; virtual ~Clickable() default; }; class Button : public Drawable, public Clickable { public: void draw() const override { /* ... */ } void onClick() override { /* ... */ } };这种模式在上层设计里给类提供多角色的能力同时避免了菱形问题因为接口之间通常不会有公共基类。即便有一个公共的纯虚基类通过 virtual 继承汇聚问题也不大。经验法则多继承里带数据的基类不超过一个。超过一个时考虑拆成组合。这条规则帮我规避了绝大部分多继承相关的诡异问题。6. 我的实践总结什么时候该用继承什么时候该果断放弃6.1 接口继承与实现继承的分工继承在实践中可以分成两类接口继承和实现继承。接口继承是子类只继承父类的纯虚函数声明自己负责全部实现实现继承则是子类直接复用父类的成员和逻辑。纯虚类在 C 里没有数据成员只描述能做什么是接口继承最典型的载体也是多重继承最安全的场景。当设计一个类层次时我会先问三个问题派生类是否真的能作为基类使用基类的每一个虚函数对于每个派生类是否都有合理且完整的覆盖语义基类里的数据成员是否真的属于所有派生类的公共状态只要有一个问题的答案是否定的就应该考虑调整结构。这三个问题看着简单实际应用时很容易被图方便绑架。比如有个基类Shape有个虚函数area()正方形、圆形、三角形都能实现。这没问题。但如果为了复用某个绘制逻辑让Circle和Rectangle共同继承一个带颜色成员和填充算法的FilledShape就要小心了颜色和填充并不一定属于所有子类的本质状态。这时候把填充算法改成组合成员反而更灵活。6.2 组合优先什么时候选择has-a而不是is-a工程上翻车最多的继承问题不是语法不会写而是关系选错了。is-a 关系隐含一个承诺子类可以在所有场景下替代父类。如果这个承诺在某个派生类里打了折扣比如企鹅类不满足鸟会飞这个假设那就说明继承关系从一开始就选错了。我个人的处理原则是能用组合表达的关系不用继承表达能用接口继承表达的行为契约不轻易引入具体类之间的继承。组合的优点是关系清晰、耦合度低、不容易出现多层继承导致的语义混乱缺点是需要写一些转发代码但这点成本相比后续维护时的类层次爆炸完全值得。这里给出一个判断综合症的参考信号当你的派生类为了复用代码而出现空实现、抛异常实现、与基类语义明显冲突的实现时说明继承已经变质。比如基类定义void fly()企鹅子类只能写成throw std::logic_error(cant fly)这就是一个响亮的警告。这时候重构为组合往往能让代码重新变得直白。6.3 给初学者的学习路线建议这篇笔记从继承方式、菱形继承、虚表机制到实战坑点的顺序是按理解深度递进的。如果你正在学习这部分内容我的建议是先跟着例子手写编译执行再逐步观察内存布局和对象模型。只有真正见过加了 virtual 之后对象变大了菱形继承报二义性错误这些现象才能在头脑里建立起与语法对应的运行时模型。我在学习过程中做过一件最值的事用调试器查看派生类对象的地址布局观察对象头和虚表指针的偏移。在 GCC/Clang 下可以用-fdump-class-hierarchy直接查看虚表布局Visual Studio 的调试器里也能看到类似的结构。看得懂布局之后很多所谓的魔法就变成了必然。最后再分享一个小技巧遇到继承相关的诡异问题第一反应不要是翻语法书而是打印对象大小和地址布局。sizeof(类)、offsetof、调试器的内存视图这三样工具基本能让所有对象模型问题现出原形。希望这份笔记也能帮你少走一些弯路。