Question

Is there a reason why std::type_info is specified to be polymorphic? The destructor is specified to be virtual (and there’s a comment to the effect of “so that it’s polymorphic” in The Design and Evolution of C++). I can’t really see a compelling reason why. I don’t have any specific use case, I was just wondering if there ever was a rationale or story behind it.

---

Here’s some ideas that I’ve come up with and rejected:

1. It’s an extensibility point – implementations might define subclasses, and programs might then try to dynamic_cast a std::type_info to another, implementation-defined derived type. This is possibly the reason, but it seems that it’s just as easy for implementations to add an implementation-defined member, which could possibly be virtual. Programs wishing to test for these extensions would necessarily be non-portable anyway.
2. It’s to ensure that derived types are destroyed properly when deleteing a base pointer. But there are no standard derived types, users can’t define useful derived types, because type_info has no standard public constructors, and so deleteing a type_info pointer is never both legal and portable. And the derived types aren’t useful because they can’t be constructed – the only use I know for such non-constructible derived types is in the implementation of things like the is_polymorphic type trait.
3. It leaves open the possibility of metaclasses with customized types – each real polymorphic class A would get a derived “metaclass” A__type_info, which derives from type_info. Perhaps such derived classes could expose members that call new A with various constructor arguments in a type-safe way, and things like that. But making type_info polymorphic itself actually makes such an idea basically impossible to implement, because you’d have to have metaclasses for your metaclasses, ad infinitum, which is a problem if all the type_info objects have static storage duration. Maybe barring this is the reason for making it polymorphic.
4. There’s some use for applying RTTI features (other than dynamic_cast) to std::type_info itself, or someone thought that it was cute, or embarrassing if type_info wasn’t polymorphic. But given that there’s no standard derived type, and no other classes in the standard hierarchy which one might reasonably try cross-cast to, the question is: what? Is there a use for expressions such as typeid(std::type_info) == typeid(typeid(A))?
5. It’s because implementers will create their own private derived type (as I believe GCC does). But, why bother specifying it? Even if the destructor wasn’t specified as virtual and an implementer decided that it should be, 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.
6. It’s something to do with compilers with partially compatible ABIs coexisting, possibly as a result of dynamic linking. Perhaps implementers could recognize their own type_info subclass (as opposed to one originating from another vendor) in a portable way if type_info was guaranteed to be virtual.

The last one is the most plausible to me at the moment, but it’s pretty weak.

Answer 1

I assume it’s there for the convenience of implementers. It allows them to define extended type_info classes, and delete them through pointers to type_info at program exit, without having to build in special compiler magic to call the correct destructor, or otherwise jump through hoops.

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.

I don’t think that’s true. Consider the following:

#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);
}

Whether it’s reasonable or not, the first dynamic cast is allowed (and evaluates to a null pointer), whereas the second dynamic cast is not allowed. So, if type_info was defined in the standard to have the default non-virtual destructor, but an implementation added a virtual destructor, then a portable program could tell the difference[*].

Seems simpler to me to put the virtual destructor in the standard, than to either:

a) put a note in the standard that, although the class definition implies that type_info has no virtual functions, it is permitted to have a virtual destructor.

b) determine the set of programs which can distinguish whether type_info is polymorphic or not, and ban them all. They may not be very useful or productive programs, I don’t know, but to ban them you have to come up with some standard language that describes the specific exception you’re making to the normal rules.

Therefore I think that the standard has to either mandate the virtual destructor, or ban it. Making it optional is too complex (or perhaps I should say, I think it would be judged unnecessarily complex. Complexity never stopped the standards committee in areas where it was considered worthwhile…)

If it was banned, though, then an implementation could:

• add a virtual destructor to some derived class of type_info
• derive all of its typeinfo objects from that class
• use that internally as the polymorphic base class for everything

that would solve the situation I described at the top of the post, but the static type of a typeid expression would still be const std::type_info, so it would be difficult for implementations to define extensions where programs can dynamic_cast to various targets to see what kind of type_info object they have in a particular case. Perhaps the standard hoped to allow that, although an implementation could always offer a variant of typeid with a different static type, or guarantee that a static_cast to a certain extension class will work, and then let the program dynamic_cast from there.

In summary, as far as I know the virtual destructor is potentially useful to implementers, and removing it doesn’t gain anyone anything other than that we wouldn’t be spending time wondering why it’s there 😉

[*] Actually, I haven’t demonstrated that. I’ve demonstrated that an illegal program would, all else being equal, compile. But an implementation could perhaps work around that by ensuring that all isn’t equal, and that it doesn’t compile. Boost’s is_polymorphic isn’t portable, so while it’s possible for a program to test that a class is polymorphic, that should be, there may be no way for a conforming program to test that a class isn’t polymorphic, that shouldn’t be. I think though that even if it’s impossible, proving that, in order to remove one line from the standard, is quite a lot of effort.