【面向对象语言三大特性之 “多态”】(二)

简介: 【面向对象语言三大特性之 “多态”】(二)

2.5 重载、覆盖(重写)、隐藏(重定义)的对比

d0a8fdcdd0154ec4ba9cc4e694dc50c6.png

3. 抽象类

3.1 概念

在虚函数的后面写上 =0 ,则这个函数为纯虚函数。 包含纯虚函数的类叫做抽象类(也叫接口类),抽象类不能实例化出对象 。派生类继承后也不能实例化出对象,只有重写纯虚函数,派生 类才能实例化出对象。纯虚函数规范了派生类必须重写,另外纯虚函数更体现出了接口继承。

我们看下面一段程序:

class Car
{
public:
  virtual void Drive() = 0;
};
class Benz :public Car
{
public:
  virtual void Drive()
  {
    cout << "Benz-舒适" << endl;
  }
};
class BMW :public Car
{
public:
  virtual void Drive()
  {
    cout << "BMW-操控" << endl;
  }
};
void Test()
{
  Car* pBenz = new Benz;
  pBenz->Drive();
  Car* pBMW = new BMW;
  pBMW->Drive();
}

我们知道Car类是一个抽象类,是不能够实例化出对象的,而派生类重写了纯虚函数后就能够实例化出对象来了,纯虚函数也更好的体现了接口继承。

3.2 接口继承和实现继承

普通函数的继承是一种实现继承,派生类继承了基类函数,可以使用函数,继承的是函数的实现。虚函数的继承是一种接口继承,派生类继承的是基类虚函数的接口,目的是为了重写,达成 多态,继承的是接口。所以如果不实现多态,不要把函数定义成虚函数。

4.多态的原理

4.1虚函数表

大家看下面这一道题:(这是在X86环境下运行)

class Base
{
public:
  virtual void Func1()
  {
    cout << "Func1()" << endl;
  }
private:
  int _b = 1;
  char _c;
};
int main()
{
  cout << sizeof(Base) << endl;
  return 0;
}

如果按照我们之前的内存对齐规则,那么这个结果应该是:8

但是当我们运行程序时:


aaeb9c50dac24cbd9d6330367a944269.png

结果却是12,为什么呢?

通过观察测试我们发现 b 对象是 12bytes , 除了 _b 成员,还多一个 __vfptr 放在对象的前面 ( 注意有些

平台可能会放到对象的最后面,这个跟平台有关 ) ,对象中的这个指针我们叫做虚函数表指针 (v 代

表 virtual , f 代表 function) 。一个含有虚函数的类中都至少都有一个虚函数表指针,因为虚函数

的地址要被放到虚函数表中,虚函数表也简称虚表。

3ba7569a8ff24525bbcb24858065f335.png

那么派生类中这个表放了些什么呢?

我们可以看看接下来的程序:

class Base
{
public:
  virtual void Func1()
  {
    cout << "Base::Func1()" << endl;
  }
  virtual void Func2()
  {
    cout << "Base::Func2()" << endl;
  }
  void Func3()
  {
    cout << "Base::Func3()" << endl;
  }
private:
  int _b = 1;
};
class Derive : public Base
{
public:
  virtual void Func1()
  {
    cout << "Derive::Func1()" << endl;
  }
private:
  int _d = 2;
};
int main()
{
  Base b;
  Derive d;
  return 0;
}

我们调试起来在监视窗口上查看_vfptr指向的表中存放的是什么?


d526cae5242a490daac0bf59d9211030.png

我们发现:b的_vfptr指向的是func1和func2这两个虚函数的地址,d的_vfptr指向的虚表是拷贝b的_vfptr指向的虚表,但是由于子类中重写了func1,所以d中_vfptr指向的func1虚函数的地址发生了改变,而子类中没有重写的虚函数(func2)中的地址是不会发生改变的。

通过上面测试我们能够发现:

1. 派生类对象 d 中也有一个虚表指针, d 对象由两部分构成,一部分是父类继承下来的成员,虚表指针也就是存在这部分,另一部分是子类的成员。

2. 基类 b 对象和派生类 d 对象虚表是不一样的,这里我们发现 Func1 完成了重写,所以 d 的虚表中存的是重写的 Derive::Func1 ,所以虚函数的重写也叫作覆盖 ,覆盖就是指虚表中虚函数 的覆盖。重写是语法的叫法,覆盖是原理层的叫法。

3. 另外 Func2 继承下来后是虚函数,所以放进了虚表, Func3 也继承下来了,但不是虚函

数,所以不会放进虚表。

4. 虚函数表本质是一个存虚函数指针的指针数组,一般情况这个数组最后面放了一个 nullptr 。

5. 总结一下派生类的虚表生成: a. 先将基类中的虚表内容拷贝一份到派生类虚表中 b. 如果派生类重写了基类中某个虚函数,用派生类自己的虚函数覆盖虚表中基类的虚函数 c. 派生类自己 新增加的虚函数按其在派生类中的声明次序增加到派生类虚表的最后。

6. 这里还有一个很容易混淆的问题: 虚函数存在哪的?虚表存在哪的? 答:虚函数存在虚表,虚表存在对象中。注意上面的回答的错的 。注意 虚表存的是虚函数指针,不是虚函数 ,虚函数和普通函数一样的,都是存在代码段的,只是 他的指针又存到了虚表中。另外对象中存的不是虚表,存的是虚表指针。那么 虚表存在哪的 呢?实际我们去验证一下会发现 vs 下是存在代码段的, Linux g++ 下是存放在rodata中。

7 虚表是编译时确定还是运行时确定?虚表是在编译时就已经确定了,而虚表指针是运行时在对象中找到也就是运行时确定的,这是实现多态的关键。

8 静态成员函数能够成为虚函数吗?答案显然是不能够的,静态成员函数没有this指针,连对象地址都没有,所以根本就找不到虚表,就不能实现多态。

4.2多态的原理

上面分析了这个半天了那么多态的原理到底是什么?还记得这里 Func 函数传 Person 调用的

Person::BuyTicket ,传 Student 调用的是 Student::BuyTicket

那么为什么传入不同的对象时会调用不同的函数呢?其本质就是由于当我们传入不同对象时去不同的虚表里面找。我们在反过来思考一下,为什么形成多态的条件是父类的指针或者引用呢?

class Person {
public:
  virtual void BuyTicket() { cout << "买票-全价" << endl; }
  void fun() { cout << "fun()" << endl; }
};
class Student : public Person {
public:
  virtual void BuyTicket() { cout << "买票-半价" << endl; }
};
void Func(Person& p)
{
  p.BuyTicket();//运行时在对象里面找到虚函数表里面找
}
int main()
{
  Person Mike;
  Func(Mike);
  Student Johnson;
  Func(Johnson);
  Person& pr = Johnson;
  Person p = Johnson;
  return 0;
}

当我们不使用父类的指针或者引用时,我们调试起来观察一下:

3ffe2520f22f407babacf48b8899ea99.png


不难发现不使用父类的指针或者引用时基表指针指向的是父类的基表,那这样不就调用的是父类的虚函数了吗?就无法形成多态。有人或许会说,那为啥编译器不直接将子类的虚表拷贝给父类呢?这样不就调到了子类的虚函数了吗?但是这样做有一个很大的矛盾,就是此时父类的虚表不仅指向父类,还指向子类,这样不就乱套了吗?所以这样肯定是不可取的,换个角度如果这样允许的话那父类调用析构函数是调用父类的?还是子类的?

那为什么要虚函数覆盖呢?就是为了当我们使用不同的类型的对象时找到的虚函数的地址是不一样的,找到的虚函数不一样就自然完成了多态。

我们之前说过,多态不是在编译时确定的,而是在运行时在对象中取到地址的,我们可以通过VS的反汇编来看看:

c46f37fe28ac42268ee4b8d0d9b7b692.png

从上面我们可以明显看到当满足多态是call的不是一个具体的地址,而是在有了对象后通过对象里面的虚函数表指针来找到这张表,从虚函数表里面取到该虚函数的地址,而下面不满足多态的条件,则是在编译时就已经确定好了虚函数的地址了。

通过这里,我们在提出一个有趣的问题;假如我们把子类虚函数的访问限定符改为private,此时我们还能正常的调用子类的虚函数吗?

如果按照我们之前的理解,这样的话子类的虚函数子类外面是不可被访问的,那就不可能调到,我们运行起来试试:


84a618ba023f4ab2ab88dea6dd7b1499.png

我们惊奇的发现,居然调到了,为什么呢?

我们想想实现多态我们是通过什么调到虚函数的?是不是从对象中找到了虚函数表指针,通过该指针找到了虚函数表,在从表中调到特定的虚函数,在这个过程中,与访问限定符半毛钱关系都没有,也就是此时访问限定符是什么已经不重要了,我们是通过虚函数表来找的地址,又没有通过对象调用的方式来使用。

4.3 动态绑定与静态绑定

1. 静态绑定又称为前期绑定 ( 早绑定 ) , 在程序编译期间确定了程序的行为 , 也称为静态多态 ,比如:函数重载

2. 动态绑定又称后期绑定 ( 晚绑定 ) ,是在程序运行期间,根据具体拿到的类型确定程序的具体行为,调用具体的函数, 也称为动态多态 。

5.单继承和多继承关系的虚函数表

需要注意的是在单继承和多继承关系中,下面我们去关注的是派生类对象的虚表模型,因为基类的虚表模型前面我们已经看过了,没什么需要特别研究的。

5.1 单继承中的虚函数表

我们来看看下面这种模型(ps:用的是VS2022X86环境下验证的):

class Base {
public:
  virtual void func1() { cout << "Base::func1" << endl; }
  virtual void func2() { cout << "Base::func2" << endl; }
private:
  int a;
};
class Derive :public Base {
public:
  virtual void func1() { cout << "Derive::func1" << endl; }
  virtual void func3() { cout << "Derive::func3" << endl; }
  virtual void func4() { cout << "Derive::func4" << endl; }
private:
  int b;
};

ffdfcabdb3184952914fc8d9e18b0f44.png

我们发现bs里面的虚表指针指向的虚表里面存放的是fun1和fun2虚函数的地址,dr里面的虚表指针指向的虚表里面存放的是被重写的fun1的地址,以及拷贝过来的fun2的地址,那fun3和fun4的地址在哪里呢?其实我们可以通过内存窗口来观察观察:

a8a7999e205f4784988a63076fce9a49.png

其实fun3和fun4的地址就在fun1和fun2的后面,vs监视窗口知识没有显示出来罢了,我们打印一下在Base中func1和func2的地址和Derive中func3和func4的地址来看看:

3830002f74754a44b1b63f58210ce959.png


我们惊奇的发现居然地址不相等,其实这就是VS对真实的地址进行了封装,我们在监视窗口上看见的就是被封装的地址,这个我就不验证了,大家自己可以下去在反汇编里面验证。

为了更加直观的看见虚函数表中的地址,我们可以通过打印的方式来观察观察:

typedef void(*VFPtr) ();
void PrintVTable(VFPtr vTable[])
{
  // 依次取虚表中的虚函数指针打印并调用。调用就可以看出存的是哪个函数
  cout << " 虚表地址>" << vTable << endl;
  for (int i = 0; vTable[i] != nullptr; ++i)
  {
    printf(" 第%d个虚函数地址 :0X%p,->", i, vTable[i]);
    VFPtr f = vTable[i];
    f();//调用该函数
  }
  cout << endl;
}

为了方便打印,我们定义了一个函数指针类型,并通过该类型创建了一个函数指针数组,通过该数组(本质是一个指向函数指针数组的指针)来打印我们想要的虚函数地址。

现在问题是如何取到虚表指针,我们可以通过下面这种方式来取:

  VFPtr* VFPtrBs = (VFPtr*)( * (int*)&bs);
  PrintVTable(VFPtrBs);
  VFPtr* VFPtrDr = (VFPtr*)( * (int*)&dr);
  PrintVTable(VFPtrDr);

但是这样取大家想想还有一些其他什么问题吗?假如我们平台是64位的不就g了吗,要么写一个条件编译在不同平台下运行不同的代码(64位平台下就强转成long long类型)

更好的方式是用下面这种方式:

  VFPtr* VFPtrBs = (VFPtr*)(*(void**)&bs);
  PrintVTable(VFPtrBs);
  VFPtr* VFPtrDr = (VFPtr*)(*(void**)&dr);
  PrintVTable(VFPtrDr);

大家观察上面代码,这时无论是在哪个平台下上面代码都是正确的,我们来运行一下:

cc915424241542478e7b8176c8e37d62.png

这样看我们就能够一目了然的观察到虚函数表里面存的是谁的地址。

5.2 多继承中的虚函数表

大家看看下面的代码:

class Base1 {
public:
  virtual void func1() { cout << "Base1::func1" << endl; }
  virtual void func2() { cout << "Base1::func2" << endl; }
private:
  int b1;
};
class Base2 {
public:
  virtual void func1() { cout << "Base2::func1" << endl; }
  virtual void func2() { cout << "Base2::func2" << endl; }
private:
  int b2;
};
class Derive : public Base1, public Base2 {
public:
  virtual void func1() { cout << "Derive::func1" << endl; }
  virtual void func3() { cout << "Derive::func3" << endl; }
private:
  int d1;
};

我们定义出一个对象d,那么我们猜猜func3是在Base1中还是在Base2中?

我们来验证验证:

2a23ebe133b8451cb2c6f6cb3e8a1e75.png

大家仔细观察一下这张图,我们不难发现其实func3是在Base1中,也就是让大儿子领养。但是我们还发现了一个小问题:Base1中的func1居然与Base2中的fun1不相等(也就是图中绿色箭头),为啥捏?按道理他们应该都会被Derive重写成相同的地址,其实原因我们上面也已经提及了,VS对这个地址进行了封装,我们看到了并不是真正的地址,而是被封装后的地址,在底层中其实Base1中的func1与Base2中的fun1真实地址肯定是相同的。

我们打印起来看看:

a09da7b1a62b41d4a08191fb609f7bdd.png

这个与我们在监视窗口和内存窗口上看见的一样。

多继承派生类的未重写的虚函数放在第一个继承基类部分的虚函数表中

5.3. 菱形继承、菱形虚拟继承

实际中我们不建议设计出菱形继承及菱形虚拟继承,一方面太复杂容易出问题,另一方面这样的模型,访问基类成员有一定得性能损耗。所以菱形继承、菱形虚拟继承我们的虚表我们就不看 了,一般我们也不需要研究清楚,因为实际中很少用。如果好奇心比较强的,可以去看下面 的两篇链接文章。

C++虚函数表解析

C++对象的内存布局


目录
相关文章
|
4天前
|
人工智能 自然语言处理 文字识别
阿里云百炼Qwen3.7-Max简介:能力、优势、支持订阅计划参考
Qwen3.7-Max是阿里云百炼面向智能体时代推出的新一代旗舰模型,对标GPT-5.5、Claude Opus 4.7等闭源旗舰。该模型支持百万级token上下文窗口,具备顶级推理能力、多模态搜索与视觉理解增强、流式输出低延迟响应等核心优势,覆盖编程、办公、长周期自主执行等复杂场景。同时支持OpenAI接口兼容,便于系统快速迁移。用户可通过Token Plan团队或节省计划等订阅方式灵活调用,适合企业级高要求场景使用。
8391 37
阿里云百炼Qwen3.7-Max简介:能力、优势、支持订阅计划参考
|
3天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
4天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
572 3
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
|
4天前
|
人工智能 运维 JavaScript
阿里云Qoder CN(原通义灵码)全解析 产品形态、版本划分与技术适配说明
在AI辅助开发与智能办公工具持续普及的当下,阿里云旗下原通义灵码正式更名为Qoder CN,同时延伸出QoderWork CN、Qoder CN CLI、Qoder CN Mobile等多款配套产品,形成覆盖代码开发、日常办公、终端交互、移动端使用的完整工具矩阵。Qoder CN核心定位为AI智能编码助手,深度适配主流代码编辑器、集成开发环境以及终端场景;QoderWork CN则偏向桌面端综合办公辅助,二者面向不同使用场景,划分了多个版本档位,搭配差异化资源配额、功能权限与计费规则,同时兼容多款主流大模型。
593 4
|
4天前
|
数据采集 人工智能 前端开发
让 Coding Agent 从黑盒到透明:阿里云 Agent 观测审计数据采集实践
AI Agent 规模化落地带来执行黑盒、行为难追溯、成本难度量三大难题。阿里云基于 OTel 标准,面向 Coding Agent、个人通用助理和框架型 Agent,推出 LoongSuite Pilot、插件及探针等无侵入采集方案,让 Agent 实现可看见、可分析、可审计、可治理。
708 150
|
4天前
|
人工智能 缓存 自然语言处理
阿里Qwen3.7-Max评测:Agent能力显著提升,耗时与调用成本大幅下降
阿里云百炼推出面向智能体的旗舰大模型Qwen3.7-Max,具备长周期自主执行能力,显著提升编程、办公自动化等复杂任务处理水平;支持MCP集成与多框架兼容,并以限时5折+100万Tokens免费试用大幅降低使用门槛,助力企业高效落地AI应用。在阿里云百炼平台快速体验:https://t.aliyun.com/U/fPVHqY
1936 10
|
4天前
|
存储 安全 Java
AgentScope Java 2.0:打造分布式、企业级智能体底座
AgentScope 2.0 面向分布式部署、稳定运行、权限安全等企业级需求全面升级,打造支持多租户隔离与长期稳定运行的企业级智能体底座。
|
4天前
|
人工智能 运维 API
2026年阿里云百炼通义千问Qwen3.7-plus深度介绍 功能特性、使用优势及618大促订阅方案指南
大模型技术的普及,让AI能力逐步融入个人办公、内容创作、代码编写、企业运营、教育培训等各类场景。不同定位的模型对应不同使用需求,旗舰级模型性能强劲但使用成本偏高,轻量化模型价格低廉却难以胜任复杂任务,而介于两者之间的中端主力模型,凭借均衡的能力、亲民的定价、广泛的场景适配性,成为绝大多数个人用户、小型团队、中小企业的首选。
729 1
|
4天前
|
人工智能 安全 定位技术
CodeGraph深度解析 让Claude Code工具调用直降七成的核心原理与实操教程
如今以Claude Code为代表的AI编程智能体已经成为开发者日常编码、项目重构、漏洞修复的必备工具。但在长期使用过程中,几乎所有开发者都会遇到同一个明显痛点:AI虽然具备强大的代码生成与分析能力,却常常陷入盲目探索的循环中。
1339 2
|
4天前
|
人工智能 运维 自然语言处理
阿里云百炼Qwen3.7-Max模型详解:综合能力、核心优势与订阅计划参考指南
2026年,大模型技术持续向通用化、高性能、场景化方向迭代,阿里云百炼作为一站式大模型服务平台,持续推出迭代升级的模型产品,Qwen3.7-Max便是当前主力旗舰级大模型之一。该模型依托深度优化的底层架构与大规模训练数据,在文本理解、逻辑推理、多模态交互、代码生成、长文本处理等多个维度实现能力升级,同时搭配灵活的订阅计划体系,能够适配个人开发者、中小企业、大型企业、政企机构等不同类型用户的使用需求。
509 2