std::type_index bereikt cross-vertaaleenheid-ordening door een pointer naar een std::type_info-object in te kapselen en de vergelijking over te dragen aan de onderliggende before()-lidfunctie. De C++ ABI vereist dat de linker type-informatie voor identieke types in verschillende vertaaleenheden samenvoegt tot één canoniek object (met behulp van COMDAT-secties of zwakke symbolen), of ervoor zorgt dat before() een consistente totale volgorde biedt, ongeacht fysieke adresverschillen. Bijgevolg wikkelt std::type_index alleen deze ABI-garantie voor vergelijking, en biedt operator< en hashondersteuning zonder dat de types compleet hoeven te zijn op het moment van vergelijking. Dit mechanisme vertrouwt volledig op runtime-type-informatie (RTTI) die is ingeschakeld, omdat de compiler de type-metadata moet genereren die nodig is voor de linker om type-identiteiten over grenzen van gedeelde bibliotheken te dedupliceren of te verzoenen.
Bij het ontwerpen van een plugin-architectuur voor een game-engine hadden we een centrale registratie nodig die het typen van componenten in kaart bracht naar fabrieksfuncties. Elke plugin (gedeelde bibliotheek) registreerde zijn componenten met behulp van typeid(Component).name() als de sleutel. Tijdens cross-platform testen ontdekten we echter dat std::map-opzoeken intermittently faalde wanneer een plugin geladen in de ene gedeelde bibliotheek probeerde een fabriek op te halen die door de kernengine in een andere was geregistreerd. De onderliggende oorzaak was dat de tekenreeksnamen die door type_info::name() werden geretourneerd, verschilden tussen compilers (GCC vs Clang), en directe pointervergelijking van type_info-objecten faalde omdat elke gedeelde bibliotheek verschillende statische instanties voor hetzelfde type bevatte.
Oplossing 1: Handmatige tekenreeksnormalisatie
We overwoogden het demangelen en normaliseren van type_info::name()-tekenreeksen met behulp van compiler-specifieke API's zoals abi::__cxa_demangle om een canonieke sleutel te maken. Deze benadering beloofde menselijk leesbare identificatoren die geschikt zijn voor debugging.
Voordelen: Menselijk leesbare sleutels vergemakkelijken logging en serialisatie.
Nadelen: Demangelen is duur, tekenreeks vergelijking is langzamer dan integer vergelijking, en het formaat blijft implementatieafhankelijk, wat het risico met zich meebrengt dat toekomstige compilerupgrades het register breken.
Oplossing 2: Virtuele overerving en aangepaste RTTI
We verkenden de mogelijkheid om te vereisen dat alle componenten erven van een basisklasse die een virtuele GetTypeID()-methode biedt die een handmatig toegewezen constante integer retourneert.
Voordelen: Deterministische, snelle integer vergelijkingen en geen afhankelijkheid van compiler RTTI.
Nadelen: Handmatige ID-toewijzing is foutgevoelig (botsingen), vereist wijziging van klassehiërarchieën, en kan geen derde soorten verwerken die niet onder onze controle vallen.
Oplossing 3: Adoptie van std::type_index
We hebben het register herwerkt om std::map<std::type_index, FactoryFunc> te gebruiken, met gebruik van std::type_index(typeid(T)) als de sleutel.
Voordelen: De standaard garandeert consistente ordening en hashing over vertaaleenheden via de ABI-conforme type_info-vergelijking, vereist geen handmatig ID-beheer, en integreert naadloos met bestaande code die typeid gebruikt.
Nadelen: Vereist dat RTTI is ingeschakeld (verhoogt de binaire grootte), en type_index-objecten kunnen niet worden geserialiseerd voor netwerkoverdracht of persistente opslag.
We hebben Oplossing 3 gekozen omdat de betrouwbaarheid van type-identificatie over bibliotheken heen zwaarder woog dan de binaire groottekosten van RTTI. Het standaard voorgeschreven gedrag van std::type_index elimineerde de fragiele tekenreeks-parsing en handmatige ID-onderhoud die de alternatieven teisterden.
Het register functioneerde correct over DLL-grenzen op Linux, Windows en macOS. Fabrieksopzoeken werden O(log N) vergelijkingen van interne pointers in plaats van tekenreeksbewerkingen, wat de latency van componentinstantiatie met ongeveer 40% verminderde in vergelijking met de demangelingbenadering. Het systeem ondersteunt nu hot-reloading van plugins zonder opnieuw core engine-typen te registreren.
std::type_info::name() retourneert een implementatie-afhankelijke null-terminerende byte-reeks; de C++ standaard weigert expliciet zijn formaat, codering of stabiliteit te specificeren. Bijvoorbeeld, GCC retourneert doorgaans gemangelde namen (bijv. "St6vectorIiSaIiEE"), terwijl MSVC menselijk leesbare namen retourneert (bijv. "class std::vector<int,class std::allocator<int> >"). Compilerleveranciers kunnen deze representaties in toekomstige versies wijzigen om debugging te verbeteren of de lengte van symbolen te verkorten. Bijgevolg creëert het serialiseren van deze tekenreeksen naar schijven of netwerkprotocollen ongedefinieerd gedrag bij compilerupdates, aangezien eerder opgeslagen sleutels niet langer overeenkomen met nieuw gegenereerde sleutels. Kandidaten gaan vaak ten onrechte ervan uit dat name() zich gedraagt als een stabiele UUID.
Wanneer RTTI is uitgeschakeld, genereert de compiler geen type_info-objecten voor polymorfe types, en wordt de typeid-operator onjuist (behalve voor statische type-expressies, die statische type-informatie retourneren in sommige implementaties, maar over het algemeen is het uitgeschakeld). std::type_index vereist een const std::type_info& voor constructie, en zonder RTTI bestaan de noodzakelijke type-metadata niet in de binaire. Aangezien dit een compile-tijd afhankelijkheid is van gegenereerde metadata, genereert de compiler een foutmelding (bijv. "ongedefinieerde verwijzing naar typeinfo voor X") tijdens het linken in plaats van uit te wijken naar een vangbare runtime-exceptie. Kandidaten verwachten vaak een runtime std::bad_typeid of iets dergelijks, waardoor het wordt verward met dynamic_cast-fouten.
std::type_index slaat intern een pointer (of referentie) naar een std::type_info-object op. Niet-type sjabloonparameters in C++20 en eerder vereisen structurele types waarbij alle leden openbaar en van structurele types (of arrays daarvan) zijn, en zij kunnen geen pointers naar objecten met dynamische opslag of adresafhankelijke opslag bevatten. Aangezien type_info-objecten zich in statische opslag bevinden met linker-afhankelijke adressen, en std::type_index geen structureel type is (het heeft privé-leden en een niet-triviale copy constructor in sommige implementaties), kan het niet worden gebruikt als een NTTP. Hoewel C++23 typeid in constante expressies toestaat, blijft std::type_index zelf niet-letterlijk of niet-structureel in de meeste implementaties van de standaardbibliotheek, wat het gebruik in sjabloonargumenten waar compile-tijd constanten vereist zijn, verhindert.