std::type_index atteint l'ordre entre unités de traduction en encapsulant un pointeur vers un objet std::type_info et en déléguant la comparaison à la fonction membre before() sous-jacente. L'ABI C++ exige que le linker fusionne les informations de type pour des types identiques à travers les unités de traduction en un seul objet canonique (en utilisant des sections COMDAT ou des symboles faibles), ou garantit que before() fournit un ordre total cohérent indépendamment des différences d'adresses physiques. Par conséquent, std::type_index enveloppe simplement cette comparaison garantie par l'ABI, fournissant operator< et un support de hachage sans exiger que les types soient complets au moment de la comparaison. Ce mécanisme repose entièrement sur l'information de type à l'exécution (RTTI) étant activée, car le compilateur doit émettre les métadonnées de type nécessaires pour que le linker puisse dédupliquer ou réconcilier les identités de type à travers les frontières de bibliothèque partagée.
Lors de la conception d'une architecture de plugin pour un moteur de jeu, nous avions besoin d'un registre central mappant les types de composants aux fonctions de fabrique. Chaque plugin (bibliothèque partagée) enregistrait ses composants en utilisant typeid(Component).name() comme clé. Cependant, lors des tests multiplateformes, nous avons découvert que les recherches dans std::map échouaient de manière intermittente lorsqu'un plugin chargé dans une bibliothèque partagée tentait de récupérer une fabrique enregistrée par le moteur principal résidant dans une autre. La cause première était que les noms de chaînes retournés par type_info::name() différaient entre les compilateurs (GCC contre Clang), et que la comparaison directe des pointeurs d'objets type_info échouait car chaque bibliothèque partagée contenait des instances statiques distinctes pour le même type.
Solution 1 : Normalisation manuelle des chaînes
Nous avons envisagé de démangler et de normaliser les chaînes type_info::name() à l'aide d'APIs spécifiques au compilateur comme abi::__cxa_demangle pour créer une clé canonique. Cette approche promettait des identifiants lisibles par l'homme appropriés pour le débogage.
Avantages : Des clés lisibles par l'homme facilitent la journalisation et la sérialisation.
Inconvénients : Le démangling est coûteux, la comparaison de chaînes est plus lente que celle des entiers, et le format reste défini par l'implémentation, risquant que des mises à jour futures du compilateur ne brisent le registre.
Solution 2 : Héritage virtuel et RTTI personnalisé
Nous avons exploré l'idée d'exiger que tous les composants héritent d'une classe de base fournissant une méthode virtuelle GetTypeID() retournant une constante entière assignée manuellement.
Avantages : Comparaisons entières déterministes et rapides, aucune dépendance sur le RTTI du compilateur.
Inconvénients : L'assignation manuelle d'ID est sujette à erreur (collisions), nécessite de modifier les hiérarchies de classes, et ne peut pas gérer les types de tiers qui ne sont pas sous notre contrôle.
Solution 3 : Adoption de std::type_index
Nous avons refactorisé le registre pour utiliser std::map<std::type_index, FactoryFunc>, en utilisant std::type_index(typeid(T)) comme clé.
Avantages : La norme garantit un ordre et un hachage cohérents à travers les unités de traduction via la comparaison type_info conforme à l'ABI, ne nécessite pas de gestion manuelle des ID, et s'intègre facilement avec le code existant utilisant typeid.
Inconvénients : Nécessite que le RTTI soit activé (augmentant la taille binaire), et les objets type_index ne peuvent pas être sérialisés pour la transmission réseau ou le stockage persistant.
Nous avons sélectionné Solution 3 parce que la fiabilité de l'identification des types entre bibliothèques l'emportait sur le coût en taille binaire du RTTI. Le comportement mandataire par la norme de std::type_index a éliminé la fragile analyse de chaînes et la maintenance manuelle des ID qui affligeaient les alternatives.
Le registre fonctionnait correctement à travers les frontières DLL sur Linux, Windows et macOS. Les recherches de fabriques sont devenues des comparaisons O(log N) de pointeurs internes plutôt que des opérations sur des chaînes, réduisant la latence d'instanciation des composants d'environ 40 % par rapport à l'approche du démangling. Le système prend désormais en charge le rechargement à chaud des plugins sans réenregistrer les types du moteur principal.
std::type_info::name() retourne une chaîne de caractères d'octets terminée par un caractère nul définie par l'implémentation ; la norme C++ refuse explicitement de spécifier son format, son encodage ou sa stabilité. Par exemple, GCC retourne généralement des noms manglés (par exemple, "St6vectorIiSaIiEE"), tandis que MSVC retourne des noms lisibles (par exemple, "class std::vector<int,class std::allocator<int> >"). Les fournisseurs de compilateurs peuvent changer ces représentations dans de futures versions pour améliorer le débogage ou réduire la longueur des symboles. En conséquence, la sérialisation de ces chaînes sur disque ou dans des protocoles réseau crée un comportement indéfini lors des mises à jour du compilateur, car les clés précédemment enregistrées ne correspondraient plus à celles nouvellement générées. Les candidats supposent souvent à tort que name() se comporte comme un UUID stable.
Lorsque le RTTI est désactivé, le compilateur n'émet pas d'objets type_info pour les types polymorphes, et l'opérateur typeid devient mal formé (sauf pour les expressions de type statique, qui retournent des informations de type statique dans certaines implémentations, mais généralement il est désactivé). std::type_index nécessite un const std::type_info& pour la construction, et sans RTTI, les métadonnées de type nécessaires n'existent pas dans le binaire. Étant donné qu'il s'agit d'une dépendance à la compilation sur les métadonnées générées, le compilateur émet une erreur (par exemple, "référence indéfinie à typeinfo for X") pendant la liaison plutôt que de différer à une exception d'exécution attrapable. Les candidats s'attendent souvent à un std::bad_typeid ou similaire à l'exécution, le confondant avec les échecs de dynamic_cast.
std::type_index stocke un pointeur (ou référence) vers un objet std::type_info en interne. Les paramètres de modèle non-type dans C++20 et avant nécessitent des types structurels où tous les membres sont publics et de types structurels (ou des tableaux de ceux-ci), et ils ne peuvent pas contenir de pointeurs vers des objets avec des adresses de stockage ou de liaison dynamiques. Étant donné que les objets type_info résident dans un stockage statique avec des adresses dépendant du linker, et que std::type_index n'est pas un type structurel (il a des membres privés et un constructeur de copie non trivial dans certaines implémentations), il ne peut pas être utilisé comme un NTTP. Même si C++23 permet typeid dans des expressions constantes, std::type_index lui-même reste non-littéral ou non-structural dans la plupart des implémentations de la bibliothèque standard, empêchant son utilisation dans des arguments de modèle où des constantes à la compilation sont requises.