Title
type_info's destructor shouldn't be required to be virtual
Status
open
Section
[type.info]
Submitter
Stephan T. Lavavej

Created on 2014-06-12.00:00:00 last changed 93 months ago

Messages

Date: 2016-08-02.17:19:11

Proposed resolution:

This wording is relative to N3936.

  1. Change [type.info] as indicated:

    namespace std {
      class type_info {
      public:
        virtualsee below ~type_info();
        […]
      };
    }
    

    -1- The class type_info describes type information generated by the implementation. Objects of this class effectively store a pointer to a name for the type, and an encoded value suitable for comparing two types for equality or collating order. The names, encoding rule, and collating sequence for types are all unspecified and may differ between programs. Whether ~type_info() is virtual is implementation-defined.

Date: 2016-08-02.17:19:11

[ 2016-08 Chicago ]

No update from STL. Set priority to P3

Date: 2016-08-06.21:31:18

[ 2016-06 ]

On the reflector, STL wrote:

We'll prototype this change and report back with data in the future.

Date: 2015-05-22.19:58:39

[ Lenexa 2015-05-05: Move to Open ]

Marshall to poll LEWG for their opinion

Date: 2014-06-12.00:00:00

type_info's destructor is depicted as being virtual, which is nearly unobservable to users (since they can't construct or copy this class, they can't usefully derive from it). However, it's technically observable (via is_polymorphic and has_virtual_destructor). It also imposes real costs on implementations, requiring them to store one vptr per type_info object, when RTTI space consumption is a significant concern.

Making this implementation-defined wouldn't affect users (who can observe this only if they're specifically looking for it) and wouldn't affect implementations who need virtual here, but it would allow other implementations to drop virtual and improve their RTTI space consumption.

Richard Smith:

It's observable in a few other ways.

std::map<void*, something> m;
m[dynamic_cast<void*>(&typeid(blah))] = stuff;

... is broken by this change, because you can't dynamic_cast a non-polymorphic class type to void*.

type_info& f();
typeid(f());

... evaluates f() at runtime without this change, and might not do so with this change.

These are probably rare things, but I can imagine at least some forms of the latter being used in SFINAE tricks.

History
Date User Action Args
2016-08-02 17:19:11adminsetmessages: + msg8328
2016-06-11 05:01:26adminsetmessages: + msg8172
2015-05-22 19:58:39adminsetmessages: + msg7448
2015-05-22 19:58:39adminsetstatus: new -> open
2014-06-14 11:37:14adminsetmessages: + msg7027
2014-06-12 00:00:00admincreate