Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is std::type_info polymorphic?

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.

like image 906
Doug Avatar asked Oct 08 '10 11:10

Doug


People also ask

What is std :: Type_info?

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.

What is typeid in C++?

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++.

Is Typeid a runtime?

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.

What is the use of Typeid () function?

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.


1 Answers

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.

like image 69
Steve Jessop Avatar answered Oct 05 '22 01:10

Steve Jessop