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:
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.delete
ing 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 delete
ing 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.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.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))
?type_info
, so a portable program wouldn't be able to tell the difference.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.
std::type_info The class type_info holds implementation-specific information about a type, including the name of the type and means to compare two types for equality or collating order. This is the class returned by the typeid operator.
The typeid operator provides a program with the ability to retrieve the actual derived type of the object referred to by a pointer or a reference. This operator, along with the dynamic_cast operator, are provided for runtime type identification (RTTI) support in C++.
Since typeid is applied to a type rather than an object, there is no runtime type information, so that overhead won't be a problem.
The typeid operator allows the type of an object to be determined at run time. The result of typeid is a const type_info& . The value is a reference to a type_info object that represents either the type-id or the type of the expression, depending on which form of typeid is used.
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:
type_info
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With