c++ - 为什么 std::type_info 是多态的？

Question

std::type_info 被指定为多态有什么原因吗？析构函数被指定为虚拟的(并且在 C++ 的设计和演进中对“使其具有多态性”的效果进行了注释)。我真的看不出一个令人信服的理由。我没有任何具体的用例，我只是想知道它背后是否有任何理由或故事。

---

以下是我提出并拒绝的一些想法:

1. 这是一个可扩展点 - 实现可能会定义子类，然后程序可能会尝试将 dynamic_cast 一个 std::type_info 到另一个实现定义的派生类型。这可能是原因，但实现添加一个实现定义的成员似乎同样容易，这可能是虚拟的。无论如何，希望测试这些扩展的程序必然是不可移植的。
2. 这是为了确保在 delete 基指针时正确销毁派生类型。但是没有标准的派生类型，用户不能定义有用的派生类型，因为 type_info 没有标准的公共(public)构造函数，所以 deleteing a type_info 指针永远是合法的和可移植的。而且派生类型没有用处，因为它们不能被构造——我知道这种不可构造派生类型的唯一用途是实现诸如 is_polymorphic 类型特征之类的东西。
3. 它为具有自定义类型的元类留下了可能性——每个真正的多态 class A 都会得到一个派生的“元类”A__type_info，它派生自 type_info。也许这样的派生类可以以类型安全的方式公开使用各种构造函数参数调用 new A 的成员，诸如此类。但是使 type_info 本身具有多态性实际上使得这样的想法基本上不可能实现，因为您必须为您的元类提供元类，无穷无尽，如果所有的 type_info 对象具有静态存储持续时间。也许除非这是使其具有多态性的原因。
4. 将 RTTI 功能(除了 dynamic_cast 之外)应用于 std::type_info 本身有一些用处，或者有人认为它很可爱，或者如果 则令人尴尬type_info 不是多态的。但是鉴于没有标准派生类型，并且标准层次结构中没有其他类可以合理地尝试交叉转换，问题是:什么？ typeid(std::type_info) == typeid(typeid(A)) 之类的表达式是否有用？
5. 这是因为实现者会创建自己的私有(private)派生类型(我相信 GCC 会这样做)。但是，为什么要指定它呢？即使析构函数没有被指定为虚拟的并且实现者决定它应该是，该实现肯定可以将它声明为虚拟的，因为它不会改变 type_info 上允许的操作集，所以可移植程序无法区分。
6. 这与部分兼容的 ABI 共存的编译器有关，可能是动态链接的结果。如果 type_info 被保证是虚拟的，那么实现者或许可以以可移植的方式识别他们自己的 type_info 子类(而不是源自另一个供应商的子类)。

目前对我来说最后一个是最合理的，但它很弱。

Answer 1

我认为它的存在是为了方便实现者。它允许他们定义扩展的 type_info 类，并在程序退出时通过指向 type_info 的指针删除它们，而无需构建特殊的编译器魔法来调用正确的析构函数，或者以其他方式跳过篮球。

surely that implementation could declare it virtual, because it doesn't change the set of allowed operations on type_info, so a portable program wouldn't be able to tell the difference.

我认为这不是真的。考虑以下几点:

#include <typeinfo>

struct A {
    int x;
};

struct B {
    int x;
};

int main() {
    const A *a1 = dynamic_cast<const A*>(&typeid(int));
    B b;
    const A *a2 = dynamic_cast<const A*>(&b);
}

无论是否合理，第一次动态转换都是允许的(并且计算结果为空指针)，而第二次动态转换是不允许的。因此，如果 type_info 在标准中被定义为具有默认的非虚拟析构函数，但实现添加了虚拟析构函数，那么可移植程序可以分辨出差异[*]。

对我来说，将虚拟析构函数放在标准中似乎比任何一个都简单:

a) 在标准中注明，虽然类定义暗示 type_info 没有虚函数，但允许有虚析构函数。

b) 确定能够区分type_info 是否为多态的程序集，将其全部禁止。我不知道它们可能不是很有用或生产效率的程序，但要禁止它们，您必须想出一些标准语言来描述您对正常规则所做的特定异常(exception)。

因此，我认为标准必须强制使用虚拟析构函数，或者禁止它。将其设为可选太复杂(或者我应该说，我认为它会被判定为不必要的复杂。复杂性从未阻止标准委员会在认为值得的领域......)

如果它被禁止，那么实现可以:

• 为 type_info
的某些派生类添加一个虚拟析构函数
• 从那个类中派生出它所有的typeinfo对象
• 在内部使用它作为所有东西的多态基类

这将解决我在帖子顶部描述的情况，但是 typeid 表达式的静态类型仍然是 const std::type_info ，因此实现很难定义扩展，程序可以在其中 dynamic_cast 到各种目标，以查看在特定情况下它们具有什么样的 type_info 对象。也许标准希望允许这样做，尽管实现总是可以提供具有不同静态类型的 typeid 变体，或者保证某个扩展类的 static_cast 将起作用，然后让程序 dynamic_cast 从那里开始。

总而言之，据我所知，虚拟析构函数可能对实现者有用，移除它不会给任何人带来任何好处，除了我们不会花时间想知道它为什么存在 ;-)

[*] 实际上，我没有证明这一点。我已经证明一个非法程序会在其他条件相同的情况下编译。但是一个实现也许可以通过确保所有不相等并且它不会编译来解决这个问题。 Boost 的 is_polymorphic 是不可移植的，所以虽然程序可以测试一个类 是 是多态的，但应该是这样，但符合标准的程序可能无法测试一个类不是多态的，那不应该是。我认为即使不可能，但要证明这一点，为了从标准中删除一行，也需要付出很大的努力。