std::type_index erreicht eine ordnungsgemäße Vergleichbarkeit über Übersetzungseinheiten hinweg, indem es einen Zeiger auf ein std::type_info-Objekt kapselt und den Vergleich der zugrunde liegenden before()-Mitgliedsfunktion überlässt. Die C++ ABI schreibt vor, dass der Linker Typinformationen für identische Typen über Übersetzungseinheiten hinweg in ein einzelnes kanonisches Objekt zusammenführen muss (unter Verwendung von COMDAT-Abschnitten oder schwachen Symbolen) oder sicherstellen muss, dass before() eine konsistente totale Ordnung unabhängig von physischen Adressunterschieden bereitstellt. Folglich umschließt std::type_index lediglich diesen ABI-garantierten Vergleich und bietet operator< und Hashunterstützung, ohne dass die Typen zum Zeitpunkt des Vergleichs vollständig sein müssen. Dieser Mechanismus beruht vollständig auf aktivierter Laufzeittypinformation (RTTI), da der Compiler die erforderlichen Typmetadaten ausgeben muss, damit der Linker die Typidentitäten über die Grenzen von Shared Libraries hinweg deduplizieren oder bereinigen kann.
Bei der Gestaltung einer Plugin-Architektur für eine Spiele-Engine benötigten wir ein zentrales Register, das Komponententypen auf Fabrikfunktionen abbildet. Jedes Plugin (Shared Library) registrierte seine Komponenten mit typeid(Component).name() als Schlüssel. Während des plattformübergreifenden Tests stellten wir jedoch fest, dass std::map-Suchen intermittierend fehlschlugen, wenn ein Plugin, das in einer Shared Library geladen war, versuchte, eine von der Kern-Engine registrierte Fabrik abzurufen, die sich in einer anderen befand. Die Hauptursache war, dass die von type_info::name() zurückgegebenen Zeichenfolgen zwischen Compilern (GCC vs Clang) unterschiedlich waren und dass der direkte Zeigervergleich von type_info-Objekten fehlschlug, da jede Shared Library unterschiedliche statische Instanzen für denselben Typ enthielt.
Lösung 1: Manuelle Zeichenfolgennormalisierung
Wir betrachteten das Demangeln und Normalisieren von type_info::name()-Zeichenfolgen mit compiler-spezifischen APIs wie abi::__cxa_demangle, um einen kanonischen Schlüssel zu erstellen. Dieser Ansatz versprach menschenlesbare Identifikatoren, die sich für das Debugging eigneten.
Vorteile: Menschenlesbare Schlüssel erleichtern das Logging und die Serialisierung.
Nachteile: Das Demangeln ist teuer, Vergleiche von Zeichenfolgen sind langsamer als Vergleiche von Ganzzahlen, und das Format bleibt implementationsabhängig, was das Risiko birgt, dass zukünftige Compiler-Upgrades das Register brechen.
Lösung 2: Virtuelles Erben und benutzerdefiniertes RTTI
Wir erforschten die Anforderung, dass alle Komponenten von einer Basisklasse erben, die eine virtuelle Methode GetTypeID() bereitstellt, die eine manuell zugewiesene Ganzzahlkonstante zurückgibt.
Vorteile: Deterministische, schnelle Ganzzahlvergleiche und keine Abhängigkeit vom Compiler-RTTI.
Nachteile: Manuelle ID-Zuweisung ist fehleranfällig (Kollisionen), erfordert Änderungen an Klassenhierarchien und kann keine Drittanbieter-Typen handhaben, die nicht unter unserer Kontrolle stehen.
Lösung 3: Nutzung von std::type_index
Wir haben das Register umgestaltet, um std::map<std::type_index, FactoryFunc> zu verwenden, wobei std::type_index(typeid(T)) als Schlüssel verwendet wurde.
Vorteile: Der Standard garantiert eine konsistente Ordnung und Hashing über Übersetzungseinheiten hinweg durch den ABI-konformen type_info-Vergleich, erfordert keine manuelle ID-Verwaltung und integriert sich nahtlos mit bestehendem Code, der typeid verwendet.
Nachteile: Erfordert, dass RTTI aktiviert ist (was die BinGröße erhöht), und type_index-Objekte können nicht zur Netzwerkübertragung oder zum persistierenden Speicher serialisiert werden.
Wir wählten Lösung 3, weil die Zuverlässigkeit der typenspezifischen Identifikation über Bibliothekgrenzen hinweg die Kosten für die Binärgröße von RTTI überwogen hat. Das standardmäßig vorgeschriebene Verhalten von std::type_index beseitigte das fragile Parsen von Zeichenfolgen und die manuelle ID-Verwaltung, die die Alternativen belastete.
Das Register funktionierte korrekt über DLL-Grenzen hinweg auf Linux, Windows und macOS. Fabriksuchen wurden zu O(log N)-Vergleichen interner Zeiger und nicht zu Zeichenfolgenoperationen, was die Latenz der Komponenteninstanziierung im Vergleich zur Demanglung um etwa 40 % reduzierte. Das System unterstützt nun Hot-Reloading von Plugins, ohne dass die Typen der Kern-Engine erneut registriert werden müssen.
std::type_info::name() gibt eine implementationsdefinierte nullterminierte Bytezeichenfolge zurück; der C++-Standard lehnt es ausdrücklich ab, ihr Format, ihre Codierung oder Stabilität zu spezifizieren. Zum Beispiel gibt GCC typischerweise mangellierte Namen zurück (z.B. "St6vectorIiSaIiEE"), während MSVC menschenlesbare Namen zurückgibt (z.B. "class std::vector<int,class std::allocator<int> >"). Compileranbieter können diese Darstellungen in zukünftigen Versionen ändern, um das Debugging zu verbessern oder die Symbollängen zu reduzieren. Folglich führt das Serialisieren dieser Zeichenfolgen auf die Festplatte oder in Netzwerkprotokolle zu undefiniertem Verhalten bei Compiler-Upgrades, da zuvor gespeicherte Schlüssel nicht mehr mit neu generierten übereinstimmen. Kandidaten nehmen oft fälschlicherweise an, dass name() sich wie eine stabile UUID verhält.
Wenn RTTI deaktiviert ist, gibt der Compiler für polymorphe Typen keine type_info-Objekte aus, und der typeid-Operator wird fehlerhaft (außer bei Ausdrücken des statischen Typs, die statische Typinformationen in einigen Implementierungen zurückgeben, aber generell ist dies deaktiviert). std::type_index erfordert eine const std::type_info& zur Konstruktion, und ohne RTTI existieren die erforderlichen Typmetadaten nicht im Binärformat. Da dies eine Abhängigkeit zur Kompilierzeit auf generierte Metadaten ist, gibt der Compiler einen Fehler aus (z.B. "undefined reference to typeinfo for X") während des Linkens, anstatt eine abfängbare Laufzeitausnahme auszulösen. Kandidaten erwarten oft eine Laufzeitausnahme wie std::bad_typeid oder Ähnliches und verwechseln dies mit Fehlern bei dynamic_cast.
std::type_index speichert intern einen Zeiger (oder eine Referenz) auf ein std::type_info-Objekt. Nicht-Typ-Template-Parameter in C++20 und früher erfordern strukturierte Typen, in denen alle Mitglieder öffentlich und vom strukturellen Typ sind (oder Arrays davon) und sie können keine Zeiger auf Objekte mit dynamischem Speicher oder adressenabhängiger Bindung enthalten. Da type_info-Objekte im statischen Speicher mit linkerabhängigen Adressen residieren und std::type_index kein struktureller Typ ist (es hat private Mitglieder und einen nicht triviales Kopierkonstruktor in einigen Implementierungen), kann es nicht als NTTP verwendet werden. Obwohl C++23 typeid in konstanten Ausdrücken erlaubt, bleibt std::type_index in den meisten Implementierungen der Standardbibliothek nicht literaler oder nicht struktureller Typ, was seine Verwendung in Template-Argumenten, in denen zur Compile-Zeit Konstanten erforderlich sind, verhindert.