24. 运算符重载与多态：在继承体系中重载运算符，虚函数与运算符重载的结合

说实话，运算符重载和多态，这两个特性单独拿出来讲，很多C++开发者都能说上几句。但把它们放在一起用，尤其是在继承体系里玩出花样，这就不是人人都能驾驭的了。

我早年在一个图形引擎项目里，就踩过这个坑。当时我们设计了一个 Shape 基类，下面派生出 Circle、Rectangle。我们希望用 == 运算符来比较两个形状是否“相等”。你猜怎么着？直接重载 operator== 为虚函数？嗯，事情没那么简单。

今天我们就来聊聊，在继承体系中，运算符重载和多态到底该怎么结合。

为什么运算符重载和虚函数“天生不合”？

先看一个最直观的问题：运算符重载函数能不能是虚函数？

答案是：可以，但通常不建议。

为什么？因为运算符重载往往是二元函数，比如 a == b。而虚函数的分派机制，是基于对象的动态类型来调用。但二元运算符有两个操作数，虚函数只能对其中一个（通常是左操作数）进行动态分派。

举个例子：

class Shape {
public:
    virtual bool operator==(const Shape& other) const {
        // 基类默认实现
        return false;
    }
};

class Circle : public Shape {
public:
    bool operator==(const Shape& other) const override {
        // 这里只能知道 other 是 Shape&
        // 但 other 可能是 Circle，也可能是 Rectangle
        // 无法安全地做类型转换
        return false;
    }
};

你看，问题来了。在 Circle::operator== 里，你拿到的 other 是一个 Shape&。你想知道它是不是 Circle？得用 dynamic_cast。但如果传进来的是 Rectangle 呢？那就尴尬了。

一个更优雅的方案：非成员函数 + 虚函数辅助

我个人习惯的做法是：把运算符重载写成非成员函数，内部调用一个虚函数来做真正的比较逻辑。

这样既保留了多态的能力，又避免了二元运算符的左右操作数不对称问题。

来看代码：

class Shape {
public:
    virtual ~Shape() = default;

    // 纯虚函数：子类必须实现自己的相等判断
    virtual bool equals(const Shape& other) const = 0;

    // 提供一个类型判断接口，方便子类做类型检查
    virtual int typeId() const = 0;
};

bool operator==(const Shape& lhs, const Shape& rhs) {
    // 先判断类型是否相同
    if (lhs.typeId() != rhs.typeId()) {
        return false;
    }
    // 再调用虚函数做真正的比较
    return lhs.equals(rhs);
}

这样设计的好处很明显：

• operator== 是全局函数，左右操作数地位平等
• 真正的比较逻辑由 equals 虚函数完成，子类可以自由重写
• 类型检查由 typeId() 虚函数保证，避免跨类型比较

子类的实现就清晰多了：

class Circle : public Shape {
    double radius_;
public:
    int typeId() const override { return 1; }

    bool equals(const Shape& other) const override {
        // 此时可以安全地转型，因为 typeId 已经保证了类型一致
        const Circle& c = static_cast<const Circle&>(other);
        return std::abs(radius_ - c.radius_) < 1e-6;
    }
};

那赋值运算符呢？能不能是虚函数？

这个问题我经常被问到。答案是：不能，也不应该。

赋值运算符 operator= 必须是成员函数，而且不能是虚函数。为什么？因为赋值运算符的返回类型必须是 ClassName&，如果做成虚函数，返回类型就不一致了。

更重要的是，赋值运算符的语义是“把一个对象的值拷贝到另一个同类型的对象”。如果基类和派生类之间做赋值，就会发生切片。

我见过这样的代码：

Shape* s1 = new Circle(5.0);
Shape* s2 = new Rectangle(3.0, 4.0);
*s1 = *s2;  // 切片！只拷贝了 Shape 部分

嗯，这种写法，说白了就是给自己挖坑。赋值运算符在继承体系里，最好不要通过基类指针/引用调用。

知识体系结构图

下面这张图，帮你理清今天讲的核心逻辑：

避坑指南：我曾经踩过的几个坑

讲到这里，我想分享几个我亲身经历过的教训：

1. 不要用虚函数重载 << 和 >>
   流运算符必须是非成员函数，因为左操作数是 ostream 或 istream，不是你的类。想实现多态输出？我建议在基类里定义一个 virtual void print(ostream&) const，然后全局 operator<< 调用它。

2. 注意 const 正确性
   比较运算符通常不修改对象，所以一定要加 const。我见过有人忘了加，结果在 const 对象上调用 == 编译不过，排查了半天。

3. 小心隐藏而非覆盖
   如果你在派生类里重载了 operator==，但参数类型和基类不同，那就不是覆盖，而是隐藏。这会导致意想不到的调用行为。

什么时候真的需要运算符重载 + 多态？

说实话，这种组合并不常见。大部分时候，你只需要在具体类上重载运算符就够了。但如果你在写一个类型擦除的容器，或者一个表达式模板库，那就绕不开这个话题了。

举个例子，我在做一个几何计算库时，需要把 Circle、Rectangle、Polygon 都放到一个 vector<Shape*> 里，然后比较它们是否相等。这时候，上面的方案就派上用场了。

另一个场景是序列化。你想让所有派生类都支持 << 输出，但输出格式又各不相同。用虚函数 + 非成员运算符重载，就能优雅地解决。

好了，关于运算符重载和多态的结合，今天就聊到这里。记住一句话：运算符重载是语法层面的便利，虚函数是运行时多态的基石。把两者结合起来，关键是找到正确的委托关系。

下次你在继承体系里写 operator== 的时候，不妨想想今天讲的方案。

---