1. 核心示例：默认参数的“混血”行为
请看下面这段代码，它的输出往往会让初学者大吃一惊：
#include <iostream>
using namespace std;class Base {
public:virtual void display(int count = 10) {cout << "Base display, count = " << count << endl;}
};class Derived : public Base {
public:// 派生类重写了虚函数，并试图修改默认参数void display(int count = 20) override {cout << "Derived display, count = " << count << endl;}
};int main() {Derived d;Base* p = &d; // 向上转型：静态类型 Base*, 动态类型 Derivedp->display(); // 这里会输出什么？return 0;
}
预期 vs 现实
- 直觉预期：既然指向的是
Derived对象，应该输出Derived display, count = 20。 - 实际输出：
Derived display, count = 10
结果分析： 函数体是 Derived 的（动态绑定），但参数却是 Base 定义的（静态绑定）。这就是所谓的“混血”现象。
2. 为什么委员会要这样设计？（效率与复杂度的权衡）
C++ 之父 Bjarne Stroustrup 及其委员会做出这个决定，主要基于以下两个原因：
原因一：运行效率 (Performance)
默认参数是在函数调用点（Call Site）由编译器填入的。 如果默认参数是动态绑定的，那么编译器在编译期就无法确定该填入什么值。
- 如果实现动态默认参数：程序必须在运行期去虚函数表（Vtable）里查找当前对象对应的默认参数值。
- 代价：这会增加虚函数调用的开销。C++ 的核心哲学之一是“你不需要为你没使用的东西付费（Zero-overhead principle）”。为了一个极少用到的特性（动态默认参数）而拖慢所有虚函数的调用速度，是不符合 C++ 精神的。
原因二：实现复杂度
虚函数表（Vtable）的设计初衷是存放函数地址。 如果要求默认参数也支持多态，Vtable 就必须额外存储这些参数的值，或者存储一个能返回默认值的辅助函数地址。这会使二进制接口（ABI）变得极其复杂且难以维护。
3. 工程实践中的应对方案
由于这种“混血”行为极易引发 Bug，在实际开发中我们有两条铁律：
铁律 A：绝不重新定义继承而来的默认参数
如果你在基类写了 virtual void func(int x = 10)，在派生类里要么不写默认参数，要么必须写一模一样的 10。
铁律 B：使用 NVI 模式（Non-Virtual Interface）
这是更高级、更安全的做法。通过一个非虚函数来处理默认参数，而在内部调用一个私有的虚函数来处理逻辑。
class Shape {
public:// 非虚函数负责默认参数，它是静态绑定的，行为明确void draw(int quality = 100) {doDraw(quality);}private:// 纯虚函数负责具体实现virtual void doDraw(int q) = 0;
};class Circle : public Shape {
private:void doDraw(int q) override {cout << "Drawing circle with quality: " << q << endl;}
};
在这个模式下，无论你怎么调用 draw()，参数的来源都是唯一的（Shape 类），从而消灭了“混血”Bug。
总结
- 虚函数：动态绑定，为了灵活性（运行时决定执行逻辑）。
- 默认参数：静态绑定，为了效率（编译时直接硬编码参数值）。
这种设计虽然“奇怪”，但它体现了 C++ 对极致性能的追求。