强制覆盖来自父类的所有虚函数，来自子类

问题描述

我们正在包装一个实现抽象类 IFunctionality 的对象，在我们正在编写的一个类中也实现了 IFunctionality。

IFunctionality 接口是在第三方代码中定义的，目前它只包含虚函数，其中大部分是纯虚函数。非纯虚函数通常有一个空的实现，并在具体的实现中被覆盖。 IFunctionality 没有任何成员变量（目前）。

我们的包装器看起来像这样：

class WrapperFunctionality : public IFunctionality
{
public:
    WrapperFunctionality(IFunctionality& pOriginal)
        : m_pOriginal(pOriginal)
    {
    }

    // We override all virtual functions and forward them to the original.
    void doX() override { m_pOriginal->doX(); }
    void doY() override { m_pOriginal->doY(); }
    // ...

    // Well,except a few functions that we specialize.
    // That's why we need the wrapper.
    void doSomethingSpecial() override { ... }
};

目前一切正常。但代码将来可能会无声无息地崩溃。

问题 1：第三方代码可以向 IFunctionality 添加新的非纯虚函数。它不会被检测到，我们将无法调用原始对象中的相应函数。

问题 2：第三方代码可以将公共成员添加到 IFunctionality 并可以直接访问这些成员。我们也无法将这些修改转发到原始对象。

我想知道我们是否可以在编译时借助 static_assert 或一些模板魔术来检测这些问题。

问题 2 已在 How to detect if a class has member variables? 中讨论，但没有令人满意的解决方案。但在我看来，这种情况不太可能发生（因为这些第三方开发人员似乎并不喜欢这个接口类的公共成员变量）。

但问题 1 更有可能发生。接口类已经有非纯虚函数，很可能会有新的。有没有办法强制我的类实现该类中的所有虚函数（纯或非）？

为了澄清事情，让我对情况进行更具体的描述。

界面表示一个表面，可以在其上绘制具有给定属性的几何体：

class ISurface
{
public:
    virtual void setColor(const RGB& color) = 0;
    virtual void setopacity(float alpha) = 0;
    virtual void drawLine(...) = 0;
    virtual void drawCircle(...) = 0;
    // etc
};

一个具体的ISurface实现是由第三方框架实例化的，基于后端有多种实现。

我们的系统中有许多对象知道如何将自己绘制到 ISurface。我们不控制它们的 draw 函数。对象可以来自第三方插件：

class IDrawableObject
{
public:
    virtual void draw(ISurface* pSurface) const = 0;
};

然后是 IDrawableObject 的可能实现，可能来自第三方代码：

class SomeObject : public IDrawableObject
{
public:
    virtual void draw(ISurface* pSurface) const override
    {
        pSurface->setColor(RGB(255,0));
        pSurface->drawLine(...);
        pSurface->setopacity(0.7f);
        pSurface->fillCircle(...);
    }
};

在某些时候，我们希望通过覆盖它们的颜色或不透明度来更改这些第三方对象的视觉表示。我们可以钩入进行对象绘制调用的过程：

// That function will be called by the framework
virtual void drawObjectToSurface(const IDrawableObject* pObject,ISurface* pSurface) override
{
    pSurface->setColor(m_overrideColor);
    pSurface->setopacity(m_overrideAlpha);

    // Next line does not work as expected,because the object
    // overwrites our color and alpha before drawing itself
    //pObject->draw(pSurface); // does not work

    // Instead,we use a wrapper that blocks color and opacity writes
    BlockingSurfaceWrapper wrapperSurface(pSurface);
    pObject->draw(&wrapperSurface);
}

解决方法

我认为这两个问题都不能以可移植的方式解决，因为它们需要迭代基类属性。

第一个问题可以通过比较基类和子类的虚表并确保它们不共享任何地址来解决。请参阅gcc layout。当然，这是特定于编译器且重要的，但您可能比编译器更频繁地更新库。

但我不明白重写某些虚拟方法如何保证包装器。您可以将它们标记为 final，并使用其他纯虚方法公开类似的接口。毕竟，如果 pOriginal 自己覆盖它们会发生什么？你不理他们吗？我认为这个设计有问题。

唯一不需要运行时开销或真正的黑客攻击和类似混乱的解决方案是编写一个 libclang 分析过程，以验证所有基本虚拟方法都已被覆盖，然后将此过程作为构建的一部分运行。有许多使用 libclang 实现的各种静态分析的在线示例。这是唯一可以扩展的解决方案，一旦您开始工作，您就可以很好地将各种其他分析添加到您的构建过程中，以执行其他策略或设计要求。从长远来看，这可能是唯一的出路。

在此期间，我不会打扰任何其他黑客攻击。在实施静态分析之前，您应该将对此的检查添加到您的手动代码审查清单中，它会被审查将要提交/合并到 repo 的代码的人发现。如果您没有代码审查清单，或者更糟糕的是 - 不要审查合并请求 - 现在是时候开始了。

您将代码更改视为某种您无能为力的破坏性不可抗力是非常可疑的。这暗示您没有代码审查流程，因此生活在天气的变化中。这就是你被冻伤的原因，也是项目最终失败的原因。您与我们分享的问题只是您在捆绑包中遇到的一大堆其他问题中的一个小问题，当代码可以更改时，无需第二双眼睛查看它，没有关于合并更改的规则。

评论将解决您的所有疑虑，以防万一：

第三方代码可以向 IFunctionality 添加新的非纯虚函数 - 第三方代码应该是您的 git 存储库中的子模块，或者复制到存储库中。对第三方代码的任何更改都必须是代码审查过程的一部分，这些更改将被检查列表项捕获。
第三方代码可以将公共成员添加到 IFunctionality 并可以直接访问这些成员 - 同上，代码审查会发现这一点。

现在你问：审查第三方代码是不是很疯狂？不。它不是，因为您显然如此紧密地依赖该代码，它在功能上是代码库的一个组成部分——这就是接口设计不佳时会发生的情况。它不仅仅是一种依赖。您必须将其视为您为项目编写的任何其他代码。

生活中没有什么是免费的，当然，评论需要时间 - 清单上的项目越多，它们就越容易受到拖累。一个空的清单并不意味着你可以摆脱评论：清单应该保留到非常重要的部分，否则没有人会在确保合规性的同时保持理智。但是现在您看到您有多种选择：您可以花时间进行更长时间的代码审查，或者您可以花时间学习使用 libclang。这是一个真正的游戏规则改变者 - 就在十多年前，行业实力的静态代码分析“构建块”库只需要很多钱，或者你必须付钱给一家专门从事代码分析的公司来实施你的分析作为一个黑人—— box 使用他们为提供此类服务而开发的工具。

它要么扩展代码审查，要么实施静态分析。没办法。

c++proxy-pattern virtual-functions