std::type_index achieves cross-translation-unit ordering by encapsulating a pointer to a std::type_info object and delegating comparison to the underlying before() member function. The C++ ABI mandates that the linker merge type information for identical types across translation units into a single canonical object (using COMDAT sections or weak symbols), or ensure that before() provides a consistent total ordering regardless of physical address differences. Consequently, std::type_index merely wraps this ABI-guaranteed comparison, providing operator< and hash support without requiring the types to be complete at the point of comparison. This mechanism relies entirely on runtime type information (RTTI) being enabled, as the compiler must emit the type metadata necessary for the linker to deduplicate or reconcile type identities across shared library boundaries.
While designing a plugin architecture for a game engine, we needed a central registry mapping component types to factory functions. Each plugin (shared library) registered its components using typeid(Component).name() as the key. However, during cross-platform testing, we discovered that std::map lookups failed intermittently when a plugin loaded in one shared library attempted to retrieve a factory registered by the core engine residing in another. The root cause was that string names returned by type_info::name() differed between compilers (GCC vs Clang), and direct pointer comparison of type_info objects failed because each shared library contained distinct static instances for the same type.
Solution 1: Manual string normalization
We considered demangling and normalizing type_info::name() strings using compiler-specific APIs like abi::__cxa_demangle to create a canonical key. This approach promised human-readable identifiers suitable for debugging.
Pros: Human-readable keys facilitate logging and serialization.
Cons: Demangling is expensive, string comparison is slower than integer comparison, and the format remains implementation-defined, risking future compiler upgrades breaking the registry.
Solution 2: Virtual inheritance and custom RTTI
We explored requiring all components to inherit from a base class providing a virtual GetTypeID() method returning a manually assigned integer constant.
Pros: Deterministic, fast integer comparisons and no dependency on compiler RTTI.
Cons: Manual ID assignment is error-prone (collisions), requires modifying class hierarchies, and cannot handle third-party types not under our control.
Solution 3: Adoption of std::type_index
We refactored the registry to use std::map<std::type_index, FactoryFunc>, utilizing std::type_index(typeid(T)) as the key.
Pros: The standard guarantees consistent ordering and hashing across translation units via the ABI-compliant type_info comparison, requires no manual ID management, and integrates seamlessly with existing code using typeid.
Cons: Requires RTTI to be enabled (increasing binary size), and type_index objects cannot be serialized for network transmission or persistent storage.
We selected Solution 3 because the reliability of cross-library type identification outweighed the binary size cost of RTTI. The standard-mandated behavior of std::type_index eliminated the fragile string parsing and manual ID maintenance that plagued the alternatives.
The registry functioned correctly across DLL boundaries on Linux, Windows, and macOS. Factory lookups became O(log N) comparisons of internal pointers rather than string operations, reducing component instantiation latency by approximately 40% compared to the demangling approach. The system now supports hot-reloading of plugins without re-registering core engine types.
std::type_info::name() returns an implementation-defined null-terminated byte string; the C++ standard explicitly declines to specify its format, encoding, or stability. For example, GCC typically returns mangled names (e.g., "St6vectorIiSaIiEE"), while MSVC returns human-readable names (e.g., "class std::vector<int,class std::allocator<int> >"). Compiler vendors may change these representations in future versions to improve debugging or reduce symbol lengths. Consequently, serializing these strings to disk or network protocols creates undefined behavior upon compiler upgrades, as previously saved keys will no longer match newly generated ones. Candidates often mistakenly assume name() behaves like a stable UUID.
When RTTI is disabled, the compiler does not emit type_info objects for polymorphic types, and the typeid operator becomes ill-formed (except for expressions of static type, which return static type info in some implementations, but generally it's disabled). std::type_index requires a const std::type_info& for construction, and without RTTI, the necessary type metadata does not exist in the binary. Because this is a compile-time dependency on generated metadata, the compiler emits an error (e.g., "undefined reference to typeinfo for X") during linking rather than deferring to a catchable runtime exception. Candidates often expect a runtime std::bad_typeid or similar, confusing it with dynamic_cast failures.
std::type_index stores a pointer (or reference) to a std::type_info object internally. Non-type template parameters in C++20 and earlier require structural types where all members are public and of structural types (or arrays thereof), and they cannot contain pointers to objects with dynamic storage or linkage-dependent addresses. Since type_info objects reside in static storage with linker-dependent addresses, and std::type_index is not a structural type (it has private members and a non-trivial copy constructor in some implementations), it cannot be used as an NTTP. Even though C++23 permits typeid in constant expressions, std::type_index itself remains non-literal or non-structural in most standard library implementations, preventing its use in template arguments where compile-time constants are required.