1. 多态真正解决的问题从一段难以下咽的设计开始前阵子帮一个刚转C的同事review代码他写了一个图形绘制模块核心逻辑长这样void drawAll(vectorShape* shapes) { for (auto* s : shapes) { if (s-type() ShapeType::Circle) { static_castCircle*(s)-drawCircle(); } else if (s-type() ShapeType::Rect) { static_castRect*(s)-drawRect(); } else if (s-type() ShapeType::Triangle) { static_castTriangle*(s)-drawTriangle(); } } }这段代码不算错但每新增一种图形就得回来改这个函数——加一个else if分支。改完drawAll还不算完后面还有areaAll、serializeAll每一处都跟着加分支。图形种类到七八个的时候这些函数已经膨胀到没法看了。这就是多态要解决的问题让操作和类型解耦。你不需要在调用方去判断对象到底是谁、该走哪条分支而是把怎么画这件事交给对象自己决定。调用方只需要说一句你画吧剩下的由对象内部完成。用多态重写之后上面那段代码变成void drawAll(vectorShape* shapes) { for (auto* s : shapes) { s-draw(); // 每个对象自行决定怎么画 } }新增图形类的时候所有这把的逻辑都不用动只要新类自己实现draw()就行。这种能力在C里的核心载体就是虚函数——它让我们能通过基类指针或引用在运行时动态地调用到派生类对应的实现。这个机制还有个学名叫动态多态运行时多态。C里的多态还有另一半——编译期多态也就是模板。很多初学者以为多态就是虚函数其实模板那套同一段代码实例化成不同类型的玩法从定义上也属于多态的范畴。这篇主要讲运行时多态虚函数那一整套最后会单独聊编译期多态给你把两者的边界和使用场景都理清楚。提示下文所有代码都标注了C标准版本建议至少用C11编译运行。-stdc11起步涉及更高级特性会单独标注。2. 虚函数表与虚指针运行期多态的底层真相很多教程讲多态停留在基类指针指向派生类对象调用虚函数会执行派生类的实现这个现象层面。但如果你面试或者实际排查问题光知道现象是不够的——你得知道编译器是怎么做到这一步的。2.1 vptr和vtable的内存布局C标准没有规定虚函数必须怎么实现但主流的编译实现MSVC、GCC、Clang都选择了一个高度相似的方案每个包含虚函数的类以及从它派生的类内部会多出一个隐式的指针成员——虚指针vptr这个指针指向一张表——虚函数表vtable。这张表本质上是一个函数指针数组里面按声明顺序存放着当前类实际可用的虚函数地址。来看个具体例子class Animal { public: virtual void speak() { cout Animal speaks endl; } virtual void move() { cout Animal moves endl; } virtual ~Animal() default; }; class Dog : public Animal { public: void speak() override { cout Dog barks endl; } };对于Animal编译器生成了一个vtable里面存Animal::speak和Animal::move的地址。对于Dog它从Animal继承了vtable的结构但Dog自己没有重写move所以Dog的vtable里两个表项分别是Dog::speak和Animal::move。每个对象的内存布局简化后是这样Animal对象: ------------------ | vptr ------ vtable (Animal::speak, Animal::move) | 其他成员变量 | ------------------ Dog对象: ------------------ | vptr ------ vtable (Dog::speak, Animal::move) -- 注意Dog自己的vptr | Animal::其他成员 | | Dog::新增成员 | ------------------关键在最后一行Dog对象里的vptr指向的是Dog自己的vtable不是Animal的。所以哪怕你把一个Dog对象赋值给Animal*指针通过这个指针调用speak()时程序先访问到对象的vptr再顺着vptr找到的vtable判定——哦第一项是Dog::speak于是就跳了过去执行。这个顺着对象的vptr查表再跳转的过程就是动态绑定发生的地方。2.2 为什么基类指针能指挥派生类对象很多人问过这么一句Animal* p new Dog();p明明是个Animal*为什么p-speak()会跑到Dog的实现里去答案藏在上面的内存布局里Dog对象的内存起始位置首先是Animal子对象包含继承来的vptr和成员然后才是Dog新增的部分。基类子对象在派生类对象的前部所以Animal*指向的地址和Dog*指向的地址是一致的单继承下。此时通过Animal*只能访问到基类子对象的那部分数据但vptr是藏在基类子对象里的沿着它走就能找到完整的、真实类型的vtable。换句话说p-speak()这一句在编译期间其实并不会直接确定函数地址编译器把它编译成类似从p的vptr处取出第二个函数指针然后调用它这样的间接指令。真正执行时p指向的对象是Dog它的vptr是指向Dog的vtable的于是自然调到了Dog::speak。这也解释了多态的一个前提必须通过指针或者引用。如果你用值传递Animal a Dog(); // 类型收窄切片 a.speak(); // 调用的是 Animal::speak这就是经典的切片问题Dog对象被拷贝成一个Animal对象时vptr被重新指向了Animal的vtableDog的部分直接丢掉了。所以不要试图用值传递来享受多态老老实实用指针或引用。2.3 虚函数的性能成本虚函数不是免费的。一次虚函数调用的开销通常比普通成员函数高多少这个得分成两部分看。一是间接跳转的指令成本普通函数调用是编译期确定地址直接call虚函数需要先取vptr、再查vtable、再间接跳转多条指令但现代CPU的分支预测对这种跳转的预测成功率很高实际损失往往在几个纳秒级别。二是编译器优化的限制虚函数调用是运行时才能确定的编译器很难做内联inline。普通函数在编译期可以内联展开省去函数调用开销虚函数因为不知道最终调用谁内联几乎不可能。在性能敏感的循环里比如游戏引擎每帧调用几千次的渲染函数这个差距会被放大。我在一个实际的物理引擎里踩过这个坑一个Shape::collide()虚函数在每帧要调用几十万次性能分析发现光是查vtable的指令就占了CPU时间的大头。后来一部分热点路径改成模板 类型擦除性能提升明显。这事后面讲编译期多态的时候再细聊。3. 虚析构、纯虚函数与构造/析构期间的多态陷阱这一节全是实践中的血泪经验。多态用得多了最容易翻车的就在这几个角落。3.1 基类析构函数不写virtual等着泄漏吧先看最常见的错误class Base { public: ~Base() { /* 释放Base自己的资源 */ } }; class Derived : public Base { int* data; public: Derived() : data(new int[1024]) {} ~Derived() { delete[] data; } }; Base* p new Derived(); delete p; // 析构函数不是虚函数delete p的时候编译器看到p的静态类型是Base*于是只调用了Base::~Base()Derived的析构函数根本没被执行data指向的数组就泄漏了。**规则只要你的类设计了要作为基类被继承析构函数就应该声明为virtual。**这几乎是一条铁律没有任何例外理由。顺便说一句如果这个类不用来做多态基类那析构函数不写virtual也没问题——很多开发者为了图省事全写virtual这会带来一个副作用类里多了一个虚函数指针对象体积变大而且编译器会抑制某些优化。C Core Guidelines的建议是只对需要多态删除的基类使用虚析构普通类保持非虚析构。3.2 纯虚函数和抽象类把接口和实现分开有时候你要定义的基类根本没打算让对象直接存在它只是描述所有子类必须有什么行为。比如Shape就是典型的抽象概念你不会真的去new一个Shape你要的是Circle、Rect。这时候应该把基类的虚函数写成纯虚函数class Shape { public: virtual double area() const 0; // 纯虚函数 virtual ~Shape() default; }; class Circle : public Shape { double r; public: Circle(double radius) : r(radius) {} double area() const override { return 3.14159265358979 * r * r; } };带纯虚函数的类叫抽象类不能实例化。子类必须实现所有纯虚函数才能被实例化否则它自己也是抽象类。我在设计插件架构的时候特别喜欢这么干定义一套纯虚接口作为插件协议每个插件类去实现这套协议主程序只依赖抽象接口不关心具体插件是谁。这样插件能独立编译、动态加载主程序完全不感知插件的存在。这就是面向接口编程的核心思路。3.3 构造函数和析构函数里能调用虚函数吗能调用但结果大概率不是你要的。先看一个坑class Base { public: Base() { init(); } virtual void init() { cout Base::init endl; } }; class Derived : public Base { public: void init() override { cout Derived::init endl; } }; Derived d; // 实际输出Base::init而不是 Derived::init很多人第一反应是Derived还没构造完所以调用不到Derived的版本这个理解方向对了一半。更准确地说是在构造函数执行期间对象的动态类型是当前正在构造的类型而不是最终派生类型。道理也不难想Base的构造函数先执行此时Derived的成员变量还没初始化如果这时候虚函数调用能跑到Derived::init里而这个函数恰好访问了Derived里还没就绪的成员那就直接未定义行为了。C的设计在这里非常务实——宁可让你意外也不让你踩崩溃的坑。所以规则就是不要在构造函数或析构函数里调用虚函数它不会按你想象的动态绑定行为执行。如果确实需要在构造阶段做初始化工作可以搞一个init()普通函数由派生类构造完后再手动调用或者用CRTP那套编译期方案后文会讲。4. 重载、重写、隐藏新手最容易混淆的三兄弟网上讨论C多态的时候经常有人把重载和重写混着说实际这两者完全不是一回事。还有更隐蔽的隐藏编译器一声不吭运行结果却能让你莫名其妙。先上对比表名称英文作用域函数签名要求是否虚函数绑定时机重载overload同一作用域参数个数或类型不同不要求编译期重写override基类与派生类签名完全一致必须虚函数运行期隐藏hide基类与派生类同名即可签名不要求不要求编译期4.1 重载编译期的看参数选函数重载发生在同一个作用域里同名函数参数不同。这跟多态没关系纯粹是编译器在编译期根据你传的参数类型挑一个最匹配的版本。前面提到的热搜词里运算符优先级函数重载其实都属于编译期的名字查找 重载决议过程。它和运行期一点关系都没有。4.2 重写多态的基石重写是真正的动态多态机制。要求基类成员函数是virtual、派生类函数签名与基类完全一致协变返回类型除外这样通过基类指针/引用调用时会动态进入派生类版本。这里最容易出错的是签名不一致。比如基类virtual void draw() const;派生类写成了void draw(); // 少了const你觉得你是在重写编译器觉得你只是定义了一个新函数基类那个draw() const依然存在两个函数形成了隐藏关系。更糟糕的是你用一个Base*调用p-draw()如果指针是非const的编译期会选择Base::draw()还是Derived::draw()答案根据静态类型和名字查找规则来定经常不是你想的那样。这种问题在C11之前只能人肉排查C11引入了override关键字之后就好办多了——写错误会让编译器直接报错这部分我放在第六章讲。4.3 隐藏最阴险的同名覆盖隐藏发生在基类和派生类之间。规则是只要派生类里有和基类同名的成员函数不管参数一不一样、是不是virtual基类的那个函数在这个派生类对象的直接名字查找中就被隐藏了。来看个能坑死人的例子class Base { public: void foo(int x) { cout Base::foo(int) endl; } virtual void bar() { cout Base::bar() endl; } }; class Derived : public Base { public: void foo(double d) { cout Derived::foo(double) endl; } // 隐藏了Base::foo(int) void bar() override { cout Derived::bar() endl; } // 这是重写 };现在执行Derived d; d.foo(42); // 输出 Derived::foo(double)42被隐式转换成double你以为42是int应该调Base::foo(int)但因为在Derived的作用域里先找到了foo这个名字编译器就在这个作用域里做重载决议根本不去基类里找。所以Base::foo(int)直接连候选资格都没有。这就是隐藏在起作用。如果非要调基类的隐藏版本得用作用域限定d.Base::foo(42);这个坑在大型项目里是真的能让人debug到怀疑人生——尤其是多人协作基类加了一个新函数恰好在某层派生类里名字冲突了所有调用点悄悄地走了新版本。排查方法还是那句如果你本意是重写务必加override如果本意是隐藏建议用using显式引入基类版本避免歧义。5. 编译期多态模板与CRTP的另类解题思路运行期多态虽然用起来爽但它有几个软肋虚函数调用有间接跳转成本、类里多一个vptr导致对象变大、无法在编译期做很多优化。有些场景下我们可以换一种思路——把多态从运行时动态查找变成编译期静态决议这就是编译期多态。C里最基本的编译期多态是模板。同一个模板函数/类针对不同类型实例化出不同的版本调用的时候由编译器决定实例化的是谁。例如templatetypename T void describe(const T t) { cout t.name() endl; }这个describe可以接受任何有name()成员的类型。相比运行期多态这里没有基类的要求——只要类型有满足条件的成员就能参与。这叫做鸭子类型是编译期多态的典型形态。5.1 CRTP把虚函数搬到编译期提到编译期多态绕不开CRTPCuriously Recurring Template Pattern奇异递归模板模式。它的核心思想是派生类把自己作为模板参数传给基类基类的方法里通过static_castDerived*(this)来调用派生类的成员函数。templatetypename Derived class ShapeBase { public: void print() { static_castDerived*(this)-printImpl(); } }; class Circle : public ShapeBaseCircle { public: void printImpl() { cout Circle endl; } }; class Rect : public ShapeBaseRect { public: void printImpl() { cout Rect endl; } };这里Circle和Rect共享了print()这个公共逻辑比如打印前缀、加锁、打日志但具体的printImpl是在编译期就决定的——ShapeBaseCircle::print里调用的是Circle::printImpl不需要vptr、不需要查表编译器可以完美内联。这叫做静态多态。CRTP最常用的场景是模板方法模式基类把算法的骨架定义好把可变的步骤留给派生类去实现但绑定的时机是编译期。这在性能敏感的场景特别有价值——还是拿我物理引擎的例子碰撞检测里大量的小对象、高频调用用CRTP替代虚函数之后我实测在release模式下整体碰撞检测性能提升了约12%具体数字跟编译选项和平台相关但趋势是一致的。5.2 运行期多态 vs 编译期多态到底该选哪个两者没有绝对的优劣我的选型经验是这样的维度运行期多态虚函数编译期多态模板/CRTP绑定时机运行时编译期运行效率有查表开销难内联无额外开销可内联代码体积一份代码共享vtable每个类型实例化一份代码体积膨胀类型要求必须有共同基类只需满足接口约定鸭子类型二进制兼容好可跨插件边界差模板必须在头文件里跨.so/插件困难调试难度相对直观模板报错信息极其恐怖新手噩梦动态能力可以运行时传入任意派生类对象编译期必须确定类型结论其实很简单如果类型是在编译期就能确定、又不需要跨模块边界优先模板。如果要做插件系统、需要在运行时加载不同实现、或者需要在容器里统一存放和处理多种类型那就用虚函数。很多大型项目两者都会用——比如一个TCP服务器核心协议处理用继承虚函数管理众多消息类型工具函数用模板处理各种数据结构各司其职。6. final、override、const与多态的协同代码质量的最后一道防线这部分比较贴近C实战习惯特别是现在C11之后的现代C风格这几个关键字跟多态配合好了能挽救你无数个通宵。6.1 override编译器帮你抓重写错误override关键字是C11加入的。它不改变语义但给编译器一个承诺这个函数就是要重写基类的虚函数如果签名对不上直接编译报错。没有它的时候签名写错了编译器完全不提醒程序运行结果还特别诡异其实走进了隐藏逻辑。有了它之后至少编译期能排掉一大类错误。我现在的团队直接把重写虚函数必须加override写进了code review checklist效果立竿见影——几年前那种函数没重写但没人发现的bug基本绝迹了。class Derived : public Base { public: void draw() const override { /* 正确 */ } // void draw() override { /* 编译错误缺少const签名不匹配 */ } };6.2 final终止继续派生final用两种场景。一种是类级别的禁止这个类被继承class NoMoreChildren final : public Base { ... }; // class TryChild : NoMoreChildren {}; // 编译错误另一种是虚函数级别的禁止虚函数被继续重写class Derived : public Base { public: void draw() override final { /* 允许重写一次但不能再往下传 */ } };什么时候该用final我的经验是当你确定这个类的虚函数逻辑已经完全定死或者设计上就不希望子类篡改的时候。它能减少误用也能在编译期给当前类虚函数调用提供更多优化机会——编译器知道不会再有别的覆写版本时有些调用可以直接静态解析省掉查表。6.3 const成员函数与多态的微妙关系const和虚函数的关系很微妙。一个虚函数如果是const派生类的重写版本也必须是const否则签名不匹配除非你穿override让编译器报错。这个签名一致的规则我们已经清楚但const还有一个坑看这段代码class Base { public: virtual int get() const { return 1; } }; class Derived : public Base { public: int get() const override { return 2; } }; void printValue(const Base b) { cout b.get() endl; // 多态依然生效输出2 }const Base引用也能触发多态因为多态靠的是vptr而vptr在const和non-const版本下都存在。但要注意如果你的函数签名里写的是const Base而get()是个非const的虚函数那通过const Base是无法调用的——因为非const函数不能作用在const对象上。这就是为什么很多只读接口要设计成const虚函数否则在const场景下根本用不了多态。6.4 虚函数默认参数静态绑定和动态绑定的混合体最后一个大坑很多老手都中过招。虚函数的默认参数是静态绑定的class Base { public: virtual void func(int x 10) { cout Base, x x endl; } }; class Derived : public Base { public: void func(int x 20) override { cout Derived, x x endl; } }; Base* p new Derived(); p-func(); // 输出Derived, x10调用的是Derived::func但默认参数用的却是Base的10不是Derived默认的20。原因在于函数入口地址是动态查表决定的默认参数却在编译期就写进了调用指令里编译器根据p的静态类型Base*取默认参数10。规则很简单不要给虚函数设置默认参数。如果非要给就让基类和派生类的默认参数保持一致否则就是给自己埋雷。我在代码评审里遇到过一次两个默认参数不一致排查了半天才定位到是这个机制在作祟。7. 聊点面试之外的东西面试的时候C多态几乎是必考八股vptr、vtable、抽象类、虚析构这些概念背起来都不难。但真正在用的时候我建议你带着几个更实际的判断去写代码第一多态不是越用越好也不是越不用越好。它本质上是一种以空间换灵活性的设计。整个类层次里多一个虚函数每个对象就多一个vptr所有相关调用都不能内联。如果你在写的是一个数据密集型、性能敏感的程序能用模板解决的问题别硬套虚函数。第二设计类层次之前先想清楚谁在变化谁不该变化。虚函数应该加在那些可能因为新增需求而改变行为的接口上而不应该无脑给每个函数都加virtual。我给过不少团队的建议是优先使用纯虚接口 少量具体实现类组合优于继承。把继承用于是什么的语义建模把组合用于能不能做的功能复用这个度把握好了多态才能真正替你省维护成本。第三用多态的时候做好文档记录。因为多态把行为分散到了各个派生类里调用方看到的只有接口真正执行什么要看具体对象类型。如果一个类体系有十几个派生类新手进来根本不知道调用某个虚函数会做什么。我现在的习惯是在基类虚函数旁边写清这是模板方法中的哪个步骤默认行为是什么派生类应该注意什么这个投入在几个月后的排查中回报极高。多态是C里最优雅、也最危险的设计工具之一。掌握了底层原理、避开了那些坑之后你会发现它其实不是玄学就是一套非常实在的内存布局和编译期规则组合出来的工程能力。用对了你的代码会变得非常灵活用错了它也能让你debug到深夜。希望这篇能帮你把每个环节都摸透少走点我当年走过的弯路。
` 与测试框架对接)
