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:
- It's an extensibility point - implementations might define subclasses, and programs might then try to
dynamic_cast
astd::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. - It's to ensure that derived types are destroyed properly when
delete
ing a base pointer. But there are no standard derived types, users can't define useful derived types, becausetype_info
has no standard public constructors, and sodelete
ing atype_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 theis_polymorphic
type trait. - 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 fromtype_info
. Perhaps such derived classes could expose members that callnew A
with various constructor arguments in a type-safe way, and things like that. But makingtype_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 thetype_info
objects have static storage duration. Maybe barring this is the reason for making it polymorphic. - There's some use for applying RTTI features (other than
dynamic_cast
) tostd::type_info
itself, or someone thought that it was cute, or embarrassing iftype_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 astypeid(std::type_info) == typeid(typeid(A))
? - 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. - 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 iftype_info
was guaranteed to be virtual.
The last one is the most plausible to me at the moment, but it's pretty weak.