C 箴言：多态基类中将析构函数声明为虚拟

关注

转载最新推荐文章于 2026-08-28 14:18:40 发布 737 阅读 AI 写同款· GEO 优化 ›

Claude Managed Agents 架构解析：Session、Harness 与 Sandbox 三层抽象 Agent 运行时（Runtime）是大模型落地企业级应用的核心中间层，其本质是将模型推理、工具调用与状态管理解耦的工程范式。随着 LLM 应用从单次问答走向多步协同任务，传统上下文驱动的会话管理已无法支撑长周期、可审计、可恢复的智能体行为。Session 作为持久化事件日志、Harness 作为无状态函数路由器、Sandbox 作为按需销毁的安全执行环境，共同构成现代 Agent Runtime 的三大支柱。这一架构不仅解决静默失败、凭证泄露、调试困难等高频痛点，更推动价值重心从基础设施层向上迁移至 Tr 阅读详情

转自：http://www.west263.com/info/html/chengxusheji/C-C--/20080224/12883.html

有很多方法能够跟踪时间的轨迹，所以有必要建立一个 TimeKeeper 基类，并为不同的计时方法建立派生类：

class TimeKeeper {
　public:
　　TimeKeeper();
　　~TimeKeeper();
　...
};

class AtomicClock: public TimeKeeper { ... };
class WaterClock: public TimeKeeper { ... };
class WristWatch: public TimeKeeper { ... };

　　很多客户只是想简单地取得时间而不关心如何计算的细节，所以一个 factory 函数——返回一个指向新建派生类对象的基类指针的函数——被用来返回一个指向计时对象的指针：

TimeKeeper* getTimeKeeper(); // returns a pointer to a dynamic-
// ally allocated object of a class
// derived from TimeKeeper

　　按照 factory 函数的惯例，getTimeKeeper 返回的对象是建立在堆上的，所以为了避免泄漏内存和其他资源，最重要的就是要让每一个返回的对象都能够被完全删除。

TimeKeeper *ptk = getTimeKeeper(); // get dynamically allocated object
// from TimeKeeper hierarchy

... // use it

delete ptk; // release it to avoid resource leak

　　现在我们精力集中于上面的代码中一个更基本的缺陷：即使客户做对了每一件事，也无法预知程式将如何运转。

　　问题在于 getTimeKeeper 返回一个指向派生类对象的指针（比如 AtomicClock），那个对象通过一个基类指针（也就是个 TimeKeeper* 指针）被删除，而且这个基类（TimeKeeper）有一个非虚的析构函数。祸端就在这里，因为 C 指出：当一个派生类对象通过使用一个基类指针删除，而这个基类有一个非虚的析构函数，则结果是未定义的。运行时比较有代表性的后果是对象的派生部分不会被销毁。假如 getTimeKeeper 返回一个指向 AtomicClock 对象的指针，则对象的 AtomicClock 部分（也就是在 AtomicClock 类中声明的数据成员）很可能不会被销毁，AtomicClock 的析构函数也不会运行。然而，基类部分（也就是 TimeKeeper 部分）很可能已被销毁，这就导致了一个古怪的“部分析构”对象。这是个泄漏资源，破坏数据结构连同消耗大量调试时间的绝妙方法。排除这个问题很简单：给基类一个虚析构函数。于是，删除一个派生类对象的时候就有了您所期望的正确行为。将销毁整个对象，包括全部的派生类部分：

class TimeKeeper {
　public:
　　TimeKeeper();
　　virtual ~TimeKeeper();
　　...
};

TimeKeeper *ptk = getTimeKeeper();
...
delete ptk; // now behaves correctly

　　类似 TimeKeeper 的基类一般都包含除了析构函数以外的其他虚函数，因为虚函数的目的就是允许派生类定制实现（参见 Item 34）。例如，TimeKeeper 可能有一个虚函数 getCurrentTime，在各种不同的派生类中有不同的实现。几乎任何拥有虚函数的类差不多都应该有虚析构函数。

　　假如一个类不包含虚函数，这经常预示不打算将他作为基类使用。当一个类不打算作为基类时，将析构函数声明为虚拟通常是个坏主意。考虑一个表现二维空间中的点的类：

class Point { // a 2D point
　public:
　　Point(int xCoord, int yCoord);
　　~Point();
　private:
　　int x, y;
};

　　假如一个 int 占 32 位，一个 Point 对象正好适用于 64 位的寄存器。而且，这样一个 Point 对象能够被作为一个 64 位的量传递给其他语言写的函数，比如 C 或 FORTRAN。假如 Point 的析构函数是虚拟的，情况就完全不相同了。

　　虚函数的实现需要对象携带额外的信息，这些信息用于在运行时确定该对象应该调用哪一个虚函数。典型情况下，这一信息具备一种被称为 vptr（virtual table pointer，虚函数表指针）的指针的形式。vptr 指向一个被称为 vtbl（virtual table，虚函数表）的函数指针数组，每一个包含虚函数的类都关联到 vtbl。当一个对象调用了虚函数，实际的被调用函数通过下面的步骤确定：找到对象的 vptr 指向的 vtbl，然后在 vtbl 中寻找合适的函数指针。

　　虚函数如何被实现的细节是不重要的。重要的是假如 Point 类包含一个虚函数，这个类型的对象的大小就会增加。在一个 32 位架构中，他们将从 64 位（相当于两个 int）长到 96 位（两个 int 加上 vptr）；在一个 64 位架构中，他们可能从 64 位长到 128 位，因为在这样的架构中指针的大小是 64 位的。为 Point 加上 vptr 将会使他的大小增长 50-100%！Point 对象不再适合 64 位寄存器。而且，Point 对象在 C 和其他语言（比如 C）中，看起来不再具备相同的结构，因为其他语言缺乏 vptr 的对应物。结果，Points 不再可能传入其他语言写成的函数或从其中传出，除非您为 vptr 做出明确的对应，而这是他自己的实现细节并因此失去可移植性。

　　这里的基准就是不加选择地将任何析构函数声明为虚拟，和从不把他们声明为虚拟相同是错误的。实际上，很多人总结过这条规则：当且仅当类中至少包含一个虚拟函数时，则声明一个虚析构函数。

　　但是，当完全没有虚函数时，就可能和非虚析构函数问题发生撕咬。例如，标准 string 类型不包含虚函数，但是被误导的程式员有时将他当作基类使用：

class SpecialString: public std::string { // bad idea! std::string has a
... // non-virtual destructor
};

　　一眼看上去，这可能无伤大雅，但是，假如在程式的某个地方因为某种原因，您将一个指向 SpecialString 的指针转型为一个指向 string 的指针，然后您将 delete 施加于这个 string 指针，您就立即被送入未定义行为的领地。

SpecialString *pss = new SpecialString("Impending Doom");

std::string *ps;
...
ps = pss; // SpecialString* => std::string*
...
delete ps; // undefined! In practice,

// *ps’s SpecialString resources
// will be leaked, because the
// SpecialString destructor won’t
// be called.

　　同样的分析能够适用于任何缺少虚析构函数的类，包括全部的 STL 容器类型（例如，vector，list，set，tr1::unordered_map。假如您受到从标准容器类或任何其他带有非虚析构函数的类派生的诱惑，一定要挺住！（不幸的是，C 不提供类似 Java 的 final 类或 C# 的 sealed 类的防派生机制。）偶尔地，给一个类提供一个纯虚析构函数能提供一些便利。回想一下，纯虚函数导致抽象类——不能被实例化的类（也就是说您不能创建这个类型的对象）。有时候，您有一个类，您希望他是抽象的，但没有任何纯虚函数。怎么办呢？因为一个抽象类注定要被用作基类，又因为一个基类应该有一个虚析构函数，又因为一个纯虚函数产生一个抽象类，好了，解决方案很简单：在您希望成为抽象类的类中声明一个纯虚析构函数。这是个例子：

class AWOV { // AWOV = "Abstract w/o Virtuals"
public:
　virtual ~AWOV() = 0; // declare pure virtual destructor
};

　　这个类有一个纯虚函数，所以他是抽象的，又因为他有一个虚析构函数，所以您不必担心析构函数问题。这是个螺旋。您必须为纯虚析构函数提供一个定义：

AWOV::~AWOV() {} // definition of pure virtual dtor

　　析构函数的工作方式是：最底层的派生类（most derived class）的析构函数最先被调用，然后调用每一个基类的析构函数。编译器会产生一个从派生类的析构函数对 ~AWOV 的调用，所以您不得不确实为函数提供一个函数体。假如您不这样做，连接程式会提出抗议。

　　为基类提供虚析构函数的规则仅仅适用于多态基类——基类被设计用来允许派生类型通过基类的接口进行操作。TimeKeeper 就是个多态基类，因为我们期望能操作 AtomicClock 和 WaterClock 对象，甚至当我们仅有指向他们的类型为 TimeKeeper 的指针的时候。

　　并非任何的基类都被设计用于多态。例如，无论是标准 string 类型，还是 STL 容器类型都被完全设计成基类，可没有哪个是多态的。一些类虽然被设计用于基类，但并非被设计用于多态。这样的类——例如Uncopyable 和标准库中的 input_iterator_tag——没有被设计成允许通过基类的接口操作派生类对象。所以他们就无需虚析构函数。

　　Things to Remember

　　·多态基类应该声明虚析构函数。假如一个类有任何虚函数，他就应该有一个虚析构函数。

　　·假如不是设计用于做基类或不是设计用于多态，这样的类就不应该声明虚析构函数。

收录于