std::type_index osiąga porządek między jednostkami tłumaczenia, enkapsulując wskaźnik do obiektu std::type_info i delegując porównanie do wewnętrznej funkcji członowej before(). ABI C++ nakłada na linkera obowiązek łączenia informacji o typach dla identycznych typów w różnych jednostkach tłumaczenia w jeden obiekt kanoniczny (używając sekcji COMDAT lub słabych symboli), lub zapewnienia, że before() zapewnia spójny całkowity porządek niezależnie od różnic w adresach fizycznych. W rezultacie std::type_index jedynie owija to porównanie zapewnione przez ABI, oferując wsparcie dla operator< i haszowania bez konieczności posiadania kompletnych typów w momencie porównania. Mechanizm ten w pełni polega na włączonym typie informacji czasu wykonania (RTTI), ponieważ kompilator musi wygenerować metadane typów niezbędne dla linkera do deduplikacji lub uzgodnienia tożsamości typów w ramach granic bibliotek współdzielonych.
Podczas projektowania architektury pluginów dla silnika gry potrzebowaliśmy centralnego rejestru mapującego typy komponentów na funkcje fabrykujące. Każdy plugin (biblioteka współdzielona) rejestrował swoje komponenty przy użyciu typeid(Component).name() jako klucza. Jednak podczas testów między platformami odkryliśmy, że wyszukiwania w std::map nieudolnie zawiodły, gdy plugin załadowany w jednej bibliotece współdzielonej próbował odzyskać fabrykę zarejestrowaną przez rdzeń silnika znajdującego się w innej. Główną przyczyną było to, że nazwy ciągów zwracane przez type_info::name() różniły się między kompilatorami (GCC a Clang), a bezpośrednie porównanie wskaźników obiektów type_info nie powiodło się, ponieważ każda biblioteka współdzielona zawierała różne instancje statyczne dla tego samego typu.
Rozwiązanie 1: Ręczna normalizacja ciągów
Rozważyliśmy demangled i normalizację ciągów type_info::name() za pomocą specyficznych dla kompilatora API takich jak abi::__cxa_demangle w celu utworzenia kanonicznego klucza. To podejście obiecywało identyfikatory przystępne dla ludzi odpowiednie do debugowania.
Zalety: Klucze przyjazne dla ludzi ułatwiają logowanie i serializację.
Wady: Demangling jest kosztowny, porównanie ciągów jest wolniejsze niż porównanie liczb całkowitych, a format pozostaje zdefiniowany przez implementację, ryzykując przyszłe aktualizacje kompilatorów łamiące rejestr.
Rozwiązanie 2: Dziedziczenie wirtualne i niestandardowy RTTI
Rozważaliśmy wymóg, aby wszystkie komponenty dziedziczyły z klasy bazowej dostarczającej wirtualną metodę GetTypeID(), zwracającą ręcznie przypisaną stałą liczbę całkowitą.
Zalety: Deterministyczne, szybkie porównania liczb całkowitych i brak zależności od RTTI kompilatora.
Wady: Ręczne przypisywanie ID jest podatne na błędy (kolizje), wymaga modyfikacji hierarchii klas i nie może obsługiwać typów zewnętrznych, na które nie mamy wpływu.
Rozwiązanie 3: Przyjęcie std::type_index
Zrefaktoryzowaliśmy rejestr, aby używał std::map<std::type_index, FactoryFunc>, wykorzystując std::type_index(typeid(T)) jako klucz.
Zalety: Standard gwarantuje spójny porządek i haszowanie w różnych jednostkach tłumaczenia dzięki porównaniu type_info zgodnemu z ABI, nie wymaga ręcznego zarządzania ID i bezproblemowo integruje się z istniejącym kodem używającym typeid.
Wady: Wymaga włączenia RTTI (zwiększającego rozmiar binarny) i obiekty type_index nie mogą być serializowane do transmisji sieciowej ani trwałego przechowywania.
Wybraliśmy Rozwiązanie 3, ponieważ niezawodność identyfikacji typów między bibliotekami przewyższała koszt rozmiaru binarnego RTTI. Zachowanie wymagane przez standard dla std::type_index wyeliminowało wrażliwe analizowanie ciągów i ręczne utrzymywanie ID, które dręczyły alternatywy.
Rejestr działał poprawnie w obrębie granic DLL w systemach Linux, Windows i macOS. Wyszukiwania fabryki stały się porównaniami O(log N) wskaźników wewnętrznych, a nie operacjami na ciągach, co zmniejszyło opóźnienie instancjacji komponentów o około 40% w porównaniu do podejścia demangling. System teraz wspiera dynamiczne ładowanie pluginów bez ponownej rejestracji typów rdzenia silnika.
std::type_info::name() zwraca zdefiniowany przez implementację ciąg bajtów z zerowym terminatorem; standard C++ explicite odmawia określenia jego formatu, kodowania czy stabilności. Na przykład, GCC zazwyczaj zwraca zdemanglowane nazwy (np. "St6vectorIiSaIiEE"), podczas gdy MSVC zwraca nazwy przystępne dla ludzi (np. "class std::vector<int,class std::allocator<int> >"). Wydawcy kompilatorów mogą zmieniać te reprezentacje w przyszłych wersjach w celu ulepszenia debugowania lub skrócenia długości symboli. W rezultacie serializowanie tych ciągów na dysk lub protokoły sieciowe tworzy niezdefiniowane zachowania przy aktualizacjach kompilatora, ponieważ wcześniej zapisane klucze nie będą już pasować do nowo wygenerowanych. Kandydaci często mylnie zakładają, że name() działa jak stabilny UUID.
Gdy RTTI jest wyłączone, kompilator nie emituje obiektów type_info dla typów polimorficznych, a operator typeid staje się źle uformowany (z wyjątkiem wyrażeń statycznych, które zwracają statyczne informacje o typie w niektórych implementacjach, ale ogólnie jest to wyłączone). std::type_index wymaga const std::type_info& do konstrukcji, a bez RTTI nie istnieją w binarnym niezbędne metadane typów. Ponieważ to jest zależność w czasie kompilacji od generowanych metadanych, kompilator emituje błąd (np. "undefined reference to typeinfo for X") podczas linkowania, zamiast odwoływać się do wykrywalnego wyjątku w czasie wykonania. Kandydaci często spodziewają się wyjątków std::bad_typeid w czasie wykonania lub podobnych, myląc to z błędami dynamic_cast.
std::type_index przechowuje wewnętrznie wskaźnik (lub odniesienie) do obiektu std::type_info. Nienumeryczne parametry szablonu w C++20 i wcześniejszych wymagają typów strukturalnych, w których wszystkie człony są publiczne i typu strukturalnego (lub tablic tego typu), i nie mogą zawierać wskaźników do obiektów z dynamiczną pamięcią lub adresami zależnymi od linkera. Ponieważ obiekty type_info znajdują się w statycznej pamięci z adresami zależnymi od linkera, a std::type_index nie jest typem strukturalnym (ma prywatne człony i nie-trivialny konstruktor kopiujący w niektórych implementacjach), nie może być używany jako NTTP. Mimo że C++23 zezwala na typeid w wyrażeniach stałych, std::type_index pozostaje nie-liternym lub nie-strukturalnym w większości implementacji standardowej biblioteki, co uniemożliwia jego użycie w argumentach szablonów, gdzie wymagane są stałe w czasie kompilacji.