Quand est-ce que typeid peut renvoyer différentes instances de type_info pour le même type?

Question

Andrei Alexandrescu écrit dans Conception C ++ moderne :

  

Les objets renvoyés par typeid ont   stockage statique, de sorte que vous n'avez pas à   se soucier des problèmes de la vie.

Andrei continue:

  

La norme ne garantit pas que   chaque invocation de, disons, typeid(int)   renvoie une référence au même   type_info objet.

Même si la norme ne le garantit pas, comment cela est-il implémenté dans les compilateurs courants, tels que GCC et Visual Studio?

En supposant que &typeid(T) != &typeid(T) ne fuit pas (et renvoie une nouvelle instance à chaque appel), s'agit-il d'un & "tableau &"; par application, par unité de traduction, par dll / so ou quelque chose de complètement différent?

Y a-t-il des moments où <=>?

Les compilateurs pour Windows m'intéressent principalement, mais toute information concernant Linux et d'autres plates-formes est également appréciée.

Answer 1

  

Y a-t-il des moments où & amp; typeid (T)! = & amp; typeid (T)?

     

Les compilateurs pour Windows m'intéressent principalement, mais toute information concernant Linux et d'autres plates-formes est également appréciée.

Oui. Sous Windows, les DLL ne peuvent donc pas contenir de symboles non résolus. Si vous avez:

foo.h

struct foo { virtual ~foo() {} };

dll.cpp

#include "foo.h"
...
foo f;
cout << &typeid(&f) << endl

main.cpp

<*>

vous donnerait des indications différentes. Parce qu'avant que la dll soit chargée, typeid (foo) devrait exister en dll et en primaire primaire

Plus que cela, sous Linux, si l'exécutable principal n'était pas compilé avec -rdynamic (ou --export-dynamic), alors typeid serait résolu en différents symboles dans l'exécutable et en objet partagé (ce qui ne se produit généralement pas sous les plateformes ELF) en raison de certaines optimisations effectuées lors de la liaison de l'exécutable - suppression des symboles inutiles.

Answer 2

Les normes laissent parfois certains comportements indéterminés afin de donner une certaine liberté aux implémentations. Dans ce cas, la façon dont les types sont gérés est laissée à l’implémentation du compilateur et un ensemble de règles vous est simplement donné (essentiellement: ne vous préoccupez pas de la façon dont la mémoire est allouée pour cela).

Existe-t-il une raison particulière pour laquelle vous devez pouvoir comparer les TypeIds en fonction de leur adresse de mémoire? TypeIds substitue déjà == et! = Afin de vous permettre de les comparer et de fournir un nom () pouvant être utilisé pour les identifier de manière unique.

Si vous disposez du langage de programmation C ++ (Bjarne Stroustrup), le chapitre 15 contient de nombreux détails sur la gestion des hiérarchies de classes. Peut-être y trouverez-vous une autre solution?