std::type_index достигает упорядочивания между единицами трансляции, инкапсулируя указатель на объект std::type_info и делегируя сравнение функции-члену before(). ABI C++ требует, чтобы компоновщик сливал информацию о типах для идентичных типов между единицами трансляции в один канонический объект (используя секции COMDAT или слабые символы), или гарантировал, что before() предоставляет согласованный полный порядок независимо от различий в физических адресах. В результате std::type_index просто оборачивает это гарантированное ABI сравнение, обеспечивая поддержку operator< и хэширования без необходимости, чтобы типы были полными в момент сравнения. Этот механизм полностью зависит от включенной информации о типе во время выполнения (RTTI), так как компилятор должен сгенерировать метаданные типов, необходимые компоновщику для дедупликации или согласования типов через границы общих библиотек.
При проектировании архитектуры плагинов для игрового движка нам нужно было центральное хранилище, сопоставляющее типы компонентов с функциями фабрики. Каждый плагин (общая библиотека) регистрировал свои компоненты, используя typeid(Component).name() в качестве ключа. Однако во время кроссплатформенного тестирования мы обнаружили, что поиск в std::map иногда не удается, когда плагин, загруженный в одной общей библиотеке, пытался получить фабрику, зарегистрированную основным движком, расположенным в другой. Коренная причина заключалась в том, что строковые имена, возвращаемые type_info::name(), различались между компиляторами (GCC против Clang), и прямое сравнение указателей объектов type_info не срабатывало, поскольку каждая общая библиотека содержала разные статические экземпляры для одного и того же типа.
Решение 1: Ручная нормализация строк
Мы рассматривали деманглирование и нормализацию строк type_info::name() с использованием специфических для компилятора API, таких как abi::__cxa_demangle, чтобы создать канонический ключ. Этот подход обещал человеко-читаемые идентификаторы, подходящие для отладки.
Плюсы: Человекочитаемые ключи упрощают ведение журнала и сериализацию.
Минусы: Деманглирование дорогостоящее, сравнение строк медленнее, чем сравнение целых чисел, и формат остается определяемым реализацией, рискуя поломать реестр при будущих обновлениях компилятора.
Решение 2: Виртуальное наследование и пользовательский RTTI
Мы рассматривали требование ко всем компонентам наследоваться от базового класса, предоставляющего виртуальный метод GetTypeID(), возвращающий вручную присвоенную целую константу.
Плюсы: Определенные, быстрые сравнения целых чисел и отсутствие зависимости от RTTI компилятора.
Минусы: Ручная привязка ID подвержена ошибкам (коллизии), требует изменения иерархий классов и не может обрабатывать сторонние типы, находящиеся вне нашего контроля.
Решение 3: Принятие std::type_index
Мы переработали реестр, чтобы использовать std::map<std::type_index, FactoryFunc>, используя std::type_index(typeid(T)) в качестве ключа.
Плюсы: Стандарт гарантирует согласованное упорядочивание и хэширование между единицами трансляции через сравнение type_info, соответствующее ABI, не требует ручного управления ID и без проблем интегрируется с существующим кодом, использующим typeid.
Минусы: Требует включенной RTTI (увеличивая размер бинарного файла), и объекты type_index не могут быть сериализованы для сетевой передачи или постоянного хранения.
Мы выбрали Решение 3, потому что надежность идентификации типов между библиотеками перевесила затраты на размер бинарника от RTTI. Поведение, предписанное стандартом std::type_index, устранило хрупкий разбор строк и ручное управление ID, которые затрудняли альтернативы.
Реестр работал корректно через границы DLL на Linux, Windows и macOS. Поиски фабрик превратились в сравнения O(log N) внутренних указателей вместо операций со строками, что уменьшило задержку инстанциации компонентов примерно на 40% по сравнению с подходом с деманглированием. Теперь система поддерживает горячую перезагрузку плагинов без повторной регистрации типов основного движка.
std::type_info::name() возвращает определяемую реализацией нуль-терминированную строку; стандарт C++ явно отказывается определять его формат, кодировку или стабильность. Например, GCC обычно возвращает запутанные имена (например, "St6vectorIiSaIiEE"), в то время как MSVC возвращает человеко-читаемые имена (например, "class std::vector<int,class std::allocator<int> >"). Поставщики компиляторов могут изменить эти представления в будущих версиях для улучшения отладки или уменьшения длины символов. Следовательно, сериализация этих строк на диск или в сетевые протоколы создает неопределенное поведение при обновлениях компилятора, так как ранее сохраненные ключи больше не будут совпадать с новосгенерированными. Кандидаты часто ошибочно предполагают, что name() ведет себя как стабильный UUID.
Когда RTTI отключен, компилятор не генерирует объекты type_info для полиморфных типов, и оператор typeid становится неправильно сформированным (за исключением выражений статического типа, которые возвращают информацию статического типа в некоторых реализациях, но в общем это отключено). std::type_index требует const std::type_info& для создания, и без RTTI необходимые метаданные типов не существуют в бинарном файле. Поскольку это зависимость времени компиляции от сгенерированных метаданных, компилятор выдает ошибку (например, "неопределенная ссылка на typeinfo для X") во время компоновки, а не откладывает это до отлавливаемого исключения времени выполнения. Кандидаты часто ожидают выполнение std::bad_typeid или подобного, путая это с ошибками dynamic_cast.
std::type_index хранит указатель (или ссылку) на объект std::type_info внутри. Параметры шаблона, не относящиеся к типу, в C++20 и ранее требуют структурных типов, где все члены являются публичными и имеют структурные типы (или массивы этих типов), и они не могут содержать указатели на объекты с динамическим хранением или адресами, зависимыми от компоновщика. Поскольку объекты type_info находятся в статическом хранении с адресами, зависящими от компоновщика, и std::type_index не является структурным типом (он имеет закрытые члены и нетривиальный конструктор копирования в некоторых реализациях), его нельзя использовать в качестве NTTP. Хотя C++23 позволяет использовать typeid в константных выражениях, сам std::type_index остается нелитеральным или неструктурным в большинстве реализаций стандартной библиотеке, что препятствует его использованию в аргументах шаблона, где требуются константы времени компиляции.