1. 项目概述：为什么多态是C++的“灵魂”？

干了这么多年C++，我越来越觉得，多态（Polymorphism）这东西，就像武侠小说里的内功心法。你光会写几个类、继承几下，那叫花拳绣腿；真正能把多态玩明白、用到位，你的代码才算是有了“灵魂”，才能写出既灵活又健壮的系统。我见过太多项目，初期为了赶进度，一堆if-else或者switch-case硬编码类型判断，后期需求一变，代码就跟打满补丁的旧衣服一样，牵一发而动全身，维护成本指数级上升。

所谓多态，简单说就是“一个接口，多种实现”。在C++里，这主要靠虚函数（Virtual Function）和继承来实现。它解决的痛点非常明确：降低模块间的耦合度，提升代码的可扩展性和可维护性。想象一下，你写了一个图形渲染引擎，需要处理圆形、方形、三角形。没有多态，你可能得在draw()函数里写if (shape.type == CIRCLE) drawCircle()...。每加一种新图形，你都得去修改这个核心的draw()函数。而用了多态，你只需要定义一个抽象的Shape基类，里面有个虚函数virtual void draw() const = 0;，然后让Circle，Square，Triangle都去继承并实现自己的draw()。主循环里只需要持有Shape*的容器，统一调用shape->draw()，具体画什么，由对象自己的类型决定。新增图形类型？你只需要添加一个新类，原有的代码一行都不用动。

这不仅仅是代码看起来更“优雅”的问题，它直接关系到软件工程的核心质量。无论是开发大型游戏引擎、高频交易系统，还是嵌入式设备驱动，多态都是构建复杂、可演化系统的基石技术。接下来，我会结合我踩过的无数个坑，从设计思路、核心实现到排查技巧，把C++多态的最佳实践和那些教科书上不会写的“暗坑”给你彻底讲透。

2. 多态的核心机制与设计抉择

在动手写代码之前，我们必须先理解C++实现多态的底层机制，以及由此带来的各种设计考量。知其然，更要知其所以然，这样才能在复杂场景下做出正确选择。

2.1 虚函数表（vtable）与动态绑定的代价

C++的多态是通过虚函数表（vtable）机制实现的。这是理解一切多态行为的基础。当一个类声明了至少一个虚函数（包括纯虚函数），编译器就会为这个类生成一张虚函数表。这张表本质上是一个函数指针数组，里面按顺序存放了这个类所有虚函数的地址。同时，编译器会在这个类的每个对象实例中，隐式地添加一个指针成员（通常称为vptr），指向该类的虚函数表。

当你通过基类指针或引用调用一个虚函数时，比如basePtr->virtualFunc()，实际发生的步骤如下：

1. 通过basePtr找到对象内部的vptr。
2. 通过vptr找到该对象实际类型（可能是派生类）的虚函数表。
3. 在虚函数表中，根据虚函数的声明顺序找到virtualFunc对应的槽位（slot）。
4. 调用该槽位中存储的函数地址。

这个过程就是“动态绑定”或“晚期绑定”，它发生在程序运行时。与之相对的是“静态绑定”，即对普通成员函数的调用，在编译期就确定了具体调用哪个函数。

这里就引出了第一个关键实践：理解性能开销。动态绑定带来的开销主要来自两方面：一是每次调用需要额外的指针间接寻址（查vtable），这通常只是一两条指令，在现代CPU上开销微乎其微；二是它阻碍了编译器的内联优化。对于性能极其敏感的代码段（比如在循环最内层每秒调用上亿次的函数），虚函数调用可能成为瓶颈。

实操心得：不要过早优化。99%的场景下，虚函数调用带来的性能损失可以忽略不计，而它带来的设计收益是巨大的。只有当性能剖析器（Profiler）明确告诉你这个虚函数调用是热点时，才需要考虑其他方案（如CRTP静态多态、策略模式等）。为了那1%的可能，牺牲代码99%的清晰度和扩展性，是典型的“捡了芝麻丢了西瓜”。

2.2 继承体系的设计：何时使用公有继承？

“is-a”关系是公有继承的唯一合理理由。也就是说，当你能够肯定地说“派生类对象是一个基类对象”时，才使用公有继承。Circleis aShape，SavingsAccountis anAccount，这没问题。但“有一个”、“实现为”都不是使用公有继承的好理由。

常见陷阱：滥用继承实现代码复用。比如，你有一个Window类，带边框、标题栏。现在你要写一个Clock类，也需要显示边框和标题。如果你让Clock公有继承Window，那就意味着“Clock是一个Window”，这显然不合理。正确的做法应该是组合（Composition）：让Clock类包含一个Window成员对象，或者私有继承（但组合通常更优）。

// 错误：滥用公有继承 class Window { /* 绘制边框、标题等 */ }; class Clock : public Window { /* ... */ }; // Clock “是一个” Window？ 不合理！ // 正确：使用组合 class Clock { public: void draw() { window_.drawBorder(); // 使用窗口的功能 // ... 绘制钟表盘 } private: Window window_; // Clock “有一个” Window };

设计原则：优先使用组合，而非继承。组合提供了更大的灵活性，降低了类之间的耦合度。只有在确切的“is-a”关系，并且需要利用多态行为时，才使用公有继承。

2.3 接口类与实现类的分离

这是大型项目中提升模块性的关键技巧。我们将接口定义为只包含纯虚函数和虚析构函数的抽象类，不包含任何数据成员和具体实现。

// 接口类：只有纯虚函数，定义契约。 class IDataSerializer { public: virtual ~IDataSerializer() = default; // 接口类必须有虚析构函数 virtual std::vector<char> serialize(const Data& data) const = 0; virtual Data deserialize(const std::vector<char>& bytes) const = 0; }; // 实现类：实现接口，可以继承其他类获得实现，但对外只暴露接口。 class JsonSerializer : public IDataSerializer { public: std::vector<char> serialize(const Data& data) const override { // 具体的JSON序列化实现 } Data deserialize(const std::vector<char>& bytes) const override { // 具体的JSON反序列化实现 } }; class ProtobufSerializer : public IDataSerializer { /* ... */ };

这样做的好处是：

1. 依赖倒置：高层模块（如业务逻辑）只依赖IDataSerializer这个稳定接口，而不依赖具体的JsonSerializer或ProtobufSerializer。具体实现可以独立变化和替换。
2. 易于测试：你可以很容易地为接口创建Mock对象进行单元测试。
3. 减少编译依赖：只需要包含接口类的头文件，实现类的头文件可以通过前置声明等方式隔离，大大加快编译速度。

3. 多态实现的关键语法与陷阱规避

理解了设计思想，我们来看看在C++语法层面，有哪些必须严格遵守的规则和容易踩进去的坑。

3.1 虚析构函数：内存泄漏的“元凶”

这是C++多态中最著名、也最容易犯的错误。规则非常简单，但必须刻在脑子里：如果一个类有可能被继承，并且会通过基类指针来删除派生类对象，那么它的析构函数必须是虚函数。

class Base { public: ~Base() { std::cout << "Base dtor\n"; } // 非虚析构函数，危险！ }; class Derived : public Base { public: ~Derived() { std::cout << "Derived dtor\n"; } }; int main() { Base* ptr = new Derived(); delete ptr; // 未定义行为！通常只会调用 ~Base()，而不会调用 ~Derived()。 // 输出只有 “Base dtor”，Derived部分的资源泄漏了！ return 0; }

当delete一个指向派生类对象的基类指针时，如果基类析构函数不是虚函数，那么只会调用基类的析构函数，派生类自己的析构函数不会被调用。这会导致派生类中分配的资源（如内存、文件句柄、锁等）无法被正确释放，造成资源泄漏。

最佳实践：

• 如果一个类设计为基类（即使当前没有派生类），将其析构函数声明为virtual。
• 对于接口类（纯虚类），同样需要提供虚析构函数（如上例中的= default）。
• 反之，如果一个类不是设计用来被多态使用的（例如std::string，std::vector），就不要声明虚析构函数，避免不必要的vptr开销。

3.2 override与final关键字：让编译器成为你的保镖

C++11引入的override和final关键字，是提升代码安全性和表达力的利器。

override：明确告知编译器，这个函数意图重写基类的虚函数。如果拼写错误，或者函数签名（参数类型、常量性等）不匹配，编译器会直接报错，而不是静默地创建一个新的虚函数（隐藏了基类函数）。这能避免许多难以调试的问题。

class Base { public: virtual void foo(int) const; virtual void bar(double); }; class Derived : public Base { public: virtual void foo(int) const override; // 正确 virtual void foo(int) override; // 错误！常量性不匹配，编译报错 virtual void bar(int) override; // 错误！参数类型不匹配，编译报错 void bar(double) override; // 正确，`virtual`关键字可省略，`override`已隐含 };

final：可以用于类或虚函数。

• 用于类：class Derived final : public Base {};表示Derived不能再被继承。这有助于防止继承体系被过度扩展，也允许编译器在某些情况下进行优化（如去虚拟化）。
• 用于虚函数：virtual void func() final;表示这个虚函数在派生类中不能再被重写。这用于锁定某个关键算法的实现。

强制习惯：在派生类中重写虚函数时，总是加上override关键字。这几乎没有任何成本，却能带来巨大的安全性提升。

3.3 默认参数与虚函数：一个违反直觉的坑

这是一个经典的陷阱：虚函数是动态绑定的，但默认参数是静态绑定的。

class Base { public: virtual void print(int x = 10) const { std::cout << "Base: " << x << '\n'; } }; class Derived : public Base { public: void print(int x = 20) const override { std::cout << "Derived: " << x << '\n'; } }; int main() { Derived d; Base& b = d; b.print(); // 输出什么？ }

输出是：Derived: 10。 虽然调用的是Derived::print（动态绑定），但使用的默认参数10来自于Base::print的声明（静态绑定，在编译期根据引用b的静态类型Base&确定）。

这非常容易导致迷惑和错误。最佳实践是：避免在虚函数中使用默认参数。如果确实需要类似功能，可以考虑使用重载的非虚函数作为包装，或者使用“命名参数”等设计模式。

3.4 对象切片（Object Slicing）：多态的“杀手”

当派生类对象被以值传递的方式赋值给基类对象时，会发生对象切片。派生类特有的部分会被“切掉”，只保留基类的子对象。

class Base { int x; }; class Derived : public Base { int y; }; void func(Base b) { /* ... */ } Derived d; func(d); // 切片发生！`func`内部收到的`b`只是一个`Base`对象，没有`y`成员。 Base b = d; // 同样发生切片

切片后，对象的多态性完全丧失。通过切片得到的基类对象，其vptr指向的是基类的虚函数表，调用虚函数时只会执行基类的版本。

如何避免？

1. 使用指针或引用：在需要多态的上下文中，始终使用基类的指针（Base*）或引用（Base&）来操作对象。这是最根本的解决方法。
2. 警惕容器：std::vector<Base>存储派生类对象会发生切片。应该使用std::vector<std::unique_ptr<Base>>或std::vector<Base*>（需手动管理内存）来存储多态对象。
3. 禁止值语义：如果不想让一个类被切片，可以考虑将其拷贝构造函数和拷贝赋值运算符声明为private或=delete，并提供一个克隆虚函数（virtual Base* clone() const = 0;）。

4. 多态在复杂场景下的高级实践

掌握了基础，我们来看看在更复杂的工程实践中，如何优雅地运用多态。

4.1 工厂模式与多态对象的创建

我们通常不直接new具体的派生类，而是通过工厂方法来创建对象，这样可以将对象的创建逻辑与使用逻辑解耦。

class Product { public: virtual ~Product() = default; virtual void operate() = 0; }; class ConcreteProductA : public Product { /* ... */ }; class ConcreteProductB : public Product { /* ... */ }; class ProductFactory { public: enum class Type { A, B }; // 工厂方法：根据传入的类型标识，创建对应的产品对象。 static std::unique_ptr<Product> createProduct(Type type) { switch (type) { case Type::A: return std::make_unique<ConcreteProductA>(); case Type::B: return std::make_unique<ConcreteProductB>(); default: return nullptr; } } // 更高级的注册式工厂，避免在工厂类中硬编码所有产品类型。 using Creator = std::function<std::unique_ptr<Product>()>; static std::unordered_map<std::string, Creator>& getRegistry() { static std::unordered_map<std::string, Creator> registry; return registry; } static bool registerProduct(const std::string& name, Creator creator) { getRegistry()[name] = std::move(creator); return true; } static std::unique_ptr<Product> createProduct(const std::string& name) { auto it = getRegistry().find(name); if (it != getRegistry().end()) { return it->second(); // 调用注册的创建函数 } return nullptr; } }; // 在每个具体产品类的源文件中，进行静态注册 namespace { bool registeredA = ProductFactory::registerProduct("ProductA", [](){ return std::make_unique<ConcreteProductA>(); }); }

注册式工厂的优点是，新增产品类型时，只需要在新类的文件中进行静态注册，而无需修改工厂类的源代码，符合“开闭原则”。

4.2 使用std::unique_ptr和std::shared_ptr管理多态对象

手动管理多态对象的生命周期（new/delete）极易出错。现代C++强烈推荐使用智能指针。

• std::unique_ptr<Base>：表示独占所有权。当工厂方法返回一个产品时，这是最自然的选择。它保证了资源在任何时候都只有一个所有者，避免了内存泄漏和重复释放。

  std::unique_ptr<Product> product = factory.createProduct(type); product->operate(); // 使用 // 离开作用域时自动删除

• std::shared_ptr<Base>：表示共享所有权。当多个模块需要共同持有并访问同一个多态对象时使用。注意，直接从this指针创建shared_ptr是危险的，通常需要让类继承自std::enable_shared_from_this<Base>。

  class Observable : public std::enable_shared_from_this<Observable> { // ... }; auto obj = std::make_shared<Observable>();

关键技巧：自定义删除器。如果多态对象的析构方式不是简单的delete（比如来自DLL、使用自定义分配器），可以通过智能指针的删除器来管理。

struct CustomDeleter { void operator()(Product* p) const { // 自定义销毁逻辑，例如调用一个特定的销毁函数 p->destroy(); // 不要自己调用 delete p; } }; std::unique_ptr<Product, CustomDeleter> customProduct(ptrFromDLL);

4.3 多态与STL算法、类型擦除的结合

STL算法如std::sort，std::find_if通常要求容器元素类型支持值语义和比较操作。多态对象由于切片问题，不适合直接放入std::vector<Base>。这时，类型擦除（Type Erasure）技术就派上用场了。std::function就是一个经典的类型擦除例子。

我们可以利用多态和智能指针，实现自己的“可调用对象”容器，或者“任何类型”的容器。

// 一个简单的、支持多态比较的类型擦除包装器 class Comparable { struct Concept { virtual ~Concept() = default; virtual bool lessThan(const Concept* other) const = 0; virtual std::unique_ptr<Concept> clone() const = 0; }; template<typename T> struct Model : Concept { T data; Model(T d) : data(std::move(d)) {} bool lessThan(const Concept* other) const override { // 关键：将other转换回Model<T>进行比较 // 这里假设T支持 < 操作符。更安全的实现需要dynamic_cast和类型检查。 auto* p = dynamic_cast<const Model<T>*>(other); return p && data < p->data; } std::unique_ptr<Concept> clone() const override { return std::make_unique<Model<T>>(data); } }; std::unique_ptr<Concept> pimpl; public: template<typename T> Comparable(T value) : pimpl(std::make_unique<Model<T>>(std::move(value))) {} // 支持拷贝（需要clone） Comparable(const Comparable& other) : pimpl(other.pimpl ? other.pimpl->clone() : nullptr) {} Comparable& operator=(Comparable other) { swap(pimpl, other.pimpl); return *this; } friend bool operator<(const Comparable& a, const Comparable& b) { return a.pimpl->lessThan(b.pimpl.get()); } }; // 现在我们可以把任何支持<的类型放进同一个容器排序了 std::vector<Comparable> vec; vec.push_back(42); // int vec.push_back(std::string("hello")); // std::string vec.push_back(3.14); // double std::sort(vec.begin(), vec.end()); // 可以正常排序！

这种模式非常强大，它结合了多态的运行时灵活性和模板的编译时类型安全，是构建通用库组件（如std::any，std::function）的核心思想。

5. 多态相关的典型问题与调试技巧

即使你小心翼翼地遵循了所有最佳实践，在实际开发中依然会遇到各种稀奇古怪的问题。下面是我总结的一些常见“病症”和“药方”。

5.1 运行时类型识别（RTTI）与dynamic_cast的使用与限制

dynamic_cast和typeid是C++的RTTI机制，允许在运行时查询和转换类型。

• dynamic_cast<Derived*>(basePtr)：尝试将基类指针安全地向下转换为派生类指针。如果basePtr实际指向的对象是Derived类型或其派生类，则转换成功，返回有效指针；否则返回nullptr。对于引用类型，失败时会抛出std::bad_cast异常。

  Base* ptr = /* ... */; if (auto* dPtr = dynamic_cast<Derived*>(ptr)) { // 转换成功，可以安全使用dPtr访问Derived的特定成员 dPtr->derivedMethod(); } else { // 转换失败，ptr并不指向Derived对象 }

• typeid运算符：返回一个std::type_info对象的引用，描述表达式的类型。常用于日志、调试或实现简单的类型区分。

  if (typeid(*ptr) == typeid(Derived)) { // *ptr 的动态类型是 Derived }

然而，过度使用RTTI通常是糟糕设计的信号。它破坏了多态的封装性，迫使高层代码了解具体的派生类型。这往往意味着你的基类接口设计得不够完备，无法通过虚函数提供统一的操作。

最佳实践：

1. 优先使用虚函数：如果可以通过在基类中添加一个虚函数来解决问题，那就绝对不要用dynamic_cast。例如，与其判断类型后调用特定函数，不如在基类声明一个虚函数，让派生类各自实现。
2. 考虑访问者模式（Visitor Pattern）：当你需要对一个复杂继承结构中的多种类型进行不同操作时，访问者模式是比到处dynamic_cast更优雅、更可扩展的解决方案。
3. 理解性能与开销：dynamic_cast需要遍历继承链，可能比虚函数调用更慢。并且，RTTI通常会增加可执行文件的大小。在一些嵌入式或高性能场景下，编译器甚至会提供关闭RTTI的选项（如-fno-rtti）。
4. 确保基类至少有一个虚函数：dynamic_cast只能用于多态类型（即有虚函数的类）。

5.2 构造函数与析构函数中的虚函数调用

这是一个非常隐蔽的陷阱：在构造函数和析构函数中调用虚函数，不会发生多态行为。

class Base { public: Base() { init(); } // 在构造函数中调用虚函数 virtual void init() { std::cout << "Base::init\n"; } virtual ~Base() { cleanup(); } // 在析构函数中调用虚函数 virtual void cleanup() { std::cout << "Base::cleanup\n"; } }; class Derived : public Base { public: Derived() { /* ... */ } void init() override { std::cout << "Derived::init\n"; } void cleanup() override { std::cout << "Derived::cleanup\n"; } }; int main() { Derived d; // 输出是什么？ // 构造时：Base::init (不是 Derived::init!) // 析构时：Base::cleanup (不是 Derived::cleanup!) return 0; }

原因：在构造Derived对象时，会先调用Base的构造函数。此时，Derived对象尚未完全构造，其vptr指向的是Base的虚函数表。因此，在Base构造函数中调用的init()是Base::init。析构过程则相反，先调用Derived的析构函数，再调用Base的析构函数。在Base析构函数执行时，Derived对象的部分已经被销毁，vptr可能已被修改或指向Base的虚函数表，因此调用的是Base::cleanup。

解决方案：避免在构造/析构函数中直接调用虚函数来完成关键初始化或清理工作。可以采用以下模式：

• 传递参数给构造函数：将初始化所需的数据作为参数传递给基类构造函数。
• 使用两阶段初始化：构造函数只做最简单的成员初始化，然后提供一个独立的initialize()虚函数（或非虚函数调用虚函数）供用户显式调用。但这种方法需要注意异常安全和调用顺序。
• 将清理工作移到具体的派生类析构函数中：基类析构函数只负责清理基类自己的资源，派生类析构函数负责清理派生类的资源。这是最推荐的做法，符合RAII思想。

5.3 菱形继承与虚继承的迷雾

多重继承本身已经足够复杂，当出现“菱形继承”时，问题会加倍。

class A { public: int data; }; class B : public A {}; class C : public A {}; class D : public B, public C {}; D d; // d.data = 10; // 错误！歧义，不知道是B::data还是C::data d.B::data = 10; // 需要明确指定路径

在菱形继承中，D对象内部会有两份A的子对象（分别来自B和C）。这通常不是我们想要的，我们可能希望D只包含一份A。

虚继承（Virtual Inheritance）就是用来解决这个问题的。它保证在继承体系中，无论虚基类被派生多少次，在最终的子类对象中都只存在一个实例。

class A { public: int data; }; class B : virtual public A {}; // 虚继承 class C : virtual public A {}; // 虚继承 class D : public B, public C {}; D d; d.data = 10; // 正确！现在只有一份A子对象，没有歧义。

然而，虚继承带来了新的复杂性和开销：

1. 对象布局复杂：虚继承的对象通常包含指向虚基类子对象的指针（vbase pointer），增加了内存开销和访问间接性。
2. 初始化责任转移：在非虚继承中，每个构造函数负责初始化其直接基类。在虚继承中，最终派生类（Most Derived Class）的构造函数负责直接初始化虚基类。中间类的构造函数对虚基类的初始化会被忽略。
3. 析构顺序：析构顺序与构造顺序严格相反，同样需要特别注意。

最佳实践：尽量避免使用多重继承，尤其是菱形继承。绝大多数情况下，通过单继承和组合（包含对象成员）可以更好地表达类之间的关系。如果必须使用多重继承，优先考虑使用接口（纯虚类）的多重继承，这通常不会导致菱形问题，因为接口没有数据成员。如果确实需要共享带有状态的基类，并形成菱形结构，再谨慎考虑使用虚继承，并充分理解其带来的复杂性。

5.4 多态与异常安全

在多态环境中处理异常需要格外小心，特别是在构造函数和析构函数中。

构造函数中的异常：如果派生类构造函数中抛出异常，其基类子对象和所有已完成构造的成员子对象会被自动析构（按构造相反顺序）。但是，如果基类构造函数中已经分配了资源（如new了内存），并且在其构造函数中抛出异常，那么该基类的析构函数不会被调用（因为对象尚未完全构造）。因此，基类构造函数中获取的资源必须用智能指针或类似的RAII对象来管理，以确保异常安全。

析构函数中的异常：析构函数绝对不应该抛出异常。如果析构函数在栈展开（stack unwinding）过程中因为异常退出（即抛出异常），程序通常会直接调用std::terminate()终止。因为C++无法同时处理两个异常。对于可能失败的操作，应在析构函数内部用try-catch块捕获并处理（例如记录日志），但不要将异常传播到析构函数之外。

多态销毁与异常：当你delete一个多态对象指针时，如果派生类的析构函数抛出异常，而这个异常没有被派生类析构函数自身捕获，那么它会在传播到基类析构函数之前，导致程序终止（因为此时正处于异常处理过程中）。这进一步强调了在析构函数中吞掉或处理所有异常的必要性。

6. 性能考量与替代方案

虽然虚函数是C++多态的基石，但在极端追求性能的场景下，我们需要了解其开销并知道替代方案。

6.1 虚函数调用的真实开销分析

虚函数调用开销主要来自：

1. 间接调用：通过vptr和vtable的二次指针解引用。在现代CPU上，这通常意味着一次缓存未命中（如果vtable不在缓存中）和分支预测失败的风险。但在大多数情况下，这个开销很小（几个时钟周期）。
2. 无法内联：编译器通常无法在编译期确定调用哪个虚函数，因此无法进行内联优化。内联可以消除函数调用开销，并开启大量的优化机会（如常量传播、循环展开）。这才是虚函数在性能关键路径上的主要成本。

测量，而非猜测：在优化之前，一定要使用性能剖析工具（如perf，VTune，Callgrind）来定位真正的热点。盲目地将所有函数改为非虚，会严重损害代码设计，却可能收效甚微。

6.2 静态多态（CRTP）简介

当多态行为在编译期就能确定时，可以使用“奇异递归模板模式”（Curiously Recurring Template Pattern， CRTP）来实现静态多态，从而消除运行时开销。

// 基类模板 template <typename Derived> class Base { public: void interface() { // 将调用派发到派生类的实现 static_cast<Derived*>(this)->implementation(); } void implementation() { // 可选的默认实现 std::cout << "Default implementation in Base\n"; } }; // 派生类 class Derived1 : public Base<Derived1> { public: void implementation() { std::cout << "Custom implementation in Derived1\n"; } }; class Derived2 : public Base<Derived2> { // 没有重写implementation，将使用Base中的默认实现 }; template <typename T> void doSomething(Base<T>& obj) { obj.interface(); // 编译期绑定，可能被内联 } int main() { Derived1 d1; Derived2 d2; doSomething(d1); // 输出: Custom implementation in Derived1 doSomething(d2); // 输出: Default implementation in Base }

CRTP的优点：

• 零开销：所有函数调用在编译期确定，可以内联。
• 编译期多态：错误在编译期暴露。

CRTP的缺点：

• 运行时灵活性丧失：无法在运行时动态改变对象类型。容器中不能存放不同类型的CRTP基类指针。
• 代码膨胀：模板实例化会为每个派生类生成一份基类代码。
• 可读性降低：语法相对怪异。

适用场景：适用于性能极其关键、类型在编译期已知的场合，例如数学库中的向量/矩阵运算、特定设计模式（如策略模式）的编译期实现。

6.3 基于std::variant和std::visit的替代方案（C++17）

对于已知的、有限的类型集合，C++17的std::variant和std::visit提供了一种类型安全、且通常比基于堆分配的多态更高效的替代方案。这被称为“闭集多态”。

#include <variant> #include <iostream> class Circle { public: void draw() const { std::cout << "Drawing a circle\n"; } }; class Square { public: void draw() const { std::cout << "Drawing a square\n"; } }; using Shape = std::variant<Circle, Square>; // 形状只能是Circle或Square // 访问者，是一个可调用对象，能处理variant中的所有类型 struct DrawVisitor { void operator()(const Circle& c) const { c.draw(); } void operator()(const Square& s) const { s.draw(); } }; int main() { std::vector<Shape> shapes; shapes.emplace_back(Circle{}); shapes.emplace_back(Square{}); for (const auto& shape : shapes) { std::visit(DrawVisitor{}, shape); // 编译期生成分发代码，效率高 } // 或者使用泛型lambda (C++20更简洁) // std::visit([](const auto& s){ s.draw(); }, shape); }

优点：

• 值语义：对象通常存储在栈或容器内，内存局部性好，避免堆分配开销。
• 高效：std::visit的实现通常使用编译期生成的跳转表，比虚函数调用更快或相当。
• 类型安全：所有可能类型在编译期已知。

缺点：

• 闭集：类型集合必须预先确定，无法在运行时动态扩展。
• 可能的内存浪费：variant的大小是其所有可能类型中最大的那个，可能造成内存浪费。

选择哪种方案，取决于你的具体需求：需要运行时无限扩展的灵活性，还是对已知类型的极致性能。