std::type_index는 std::type_info 객체에 대한 포인터를 캡슐화하고 기본 before() 멤버 함수에 비교를 위임함으로써 번역 단위 간의 정렬을实现합니다. C++ ABI는 링커가 동일한 형식에 대한 형식 정보를 번역 단위 간에 단일 표준 객체로 병합하도록 의무화합니다(예: COMDAT 섹션 또는 약한 기호 사용), 또는 before()가 물리적 주소 차이에 관계없이 일관된 전체 주문을 제공하도록 보장합니다. 따라서 std::type_index는 이 ABI 보장 비교를 단순히 래핑하며, 비교 시 형식이 완료될 필요 없이 operator< 및 해시 지원을 제공합니다. 이 메커니즘은 런타임 형식 정보(RTTI)가 활성화되어야만 작동합니다. 컴파일러는 링커가 공유 라이브러리 경계를 가로질러 형식 식별자를 중복 제거하거나 조정하는 데 필요한 형식 메타데이터를 방출해야 하므로 이 기구에 의존합니다.
게임 엔진의 플러그인 아키텍처를 설계하는 과정에서 우리는 구성 요소 유형을 공장 함수에 매핑하는 중앙 레지스트리가 필요했습니다. 각 플러그인(공유 라이브러리)은 typeid(Component).name()을 키로 사용하여 자신의 구성 요소를 등록했습니다. 하지만 크로스 플랫폼 테스트 동안, 우리는 한 공유 라이브러리에서 로드된 플러그인이 다른 곳에 존재하는 코어 엔진에 의해 등록된 공장을 검색하려 할 때 std::map 조회가 간헐적으로 실패하는 것을 발견했습니다. 그 근본 원인은 type_info::name()에서 반환된 문자열 이름이 컴파일러 간(GCC와 Clang) 상이했기 때문이며, 각 공유 라이브러리가 동일한 형식에 대해 상이한 정적 인스턴스를 포함하고 있었기 때문에 type_info 객체의 직접 포인터 비교가 실패했습니다.
솔루션 1: 수동 문자열 정규화
우리는 abi::__cxa_demangle와 같은 컴파일러별 API를 사용하여 type_info::name() 문자열을 파싱하고 정규화하여 표준 키를 생성하는 방안을 고려했습니다. 이 접근법은 디버깅에 적합한 인간이 읽을 수 있는 식별자를 약속했습니다.
장점: 인간이 읽을 수 있는 키는 로깅 및 직렬화를 용이하게 합니다.
단점: 파싱은 비용이 많이 들고, 문자열 비교는 정수 비교보다 느리며, 형식은 구현에 따라 다르기 때문에 미래의 컴파일러 업그레이드 시 레지스트리가 깨질 위험이 있습니다.
솔루션 2: 가상 상속 및 사용자 지정 RTTI
우리는 모든 구성 요소가 수동으로 할당된 정수 상수를 반환하는 가상 GetTypeID() 메서드를 제공하는 기본 클래스에서 상속하도록 요구하는 방안을 탐색했습니다.
장점: 결정론적이고 빠른 정수 비교 및 컴파일러 RTTI에 의존하지 않습니다.
단점: 수동 ID 할당은 오류가 발생하기 쉽고, 클래스 계층 구조를 수정해야 하며, 우리의 제어 아래에 없는 서드파티 유형을 처리할 수 없습니다.
솔루션 3: std::type_index 채택
우리는 레지스트리를 std::map<std::type_index, FactoryFunc>를 사용하도록 리팩토링하였으며, std::type_index(typeid(T))를 키로 사용했습니다.
장점: 표준은 ABI 호환 type_info 비교를 통한 일관된 정렬 및 해싱을 보장하며, 수동 ID 관리가 필요 없고, typeid를 사용하는 기존 코드와 원활하게 통합됩니다.
단점: RTTI가 활성화되어야 하며(바이너리 크기 증가), type_index 객체는 네트워크 전송 또는 영구 저장소를 위해 직렬화될 수 없습니다.
우리는 플러그인 간의 신뢰성이 RTTI의 바이너리 크기 비용보다 중요하다고 판단하여 솔루션 3을 선택했습니다. std::type_index의 표준 고정 행동은 대안에서 발생했던 취약한 문자열 파싱 및 수동 ID 유지 관리를 제거했습니다.
레지스트리는 리눅스, 윈도우 및 macOS의 DLL 경계를 넘어 올바르게 작동했습니다. 공장 조회는 이제 문자열 연산이 아닌 내부 포인터의 O(log N) 비교가 되어, 파싱 접근 방식에 비해 구성 요소 인스턴스화 대기 시간을 약 40% 줄였습니다. 시스템은 이제 코어 엔진 유형을 다시 등록하지 않고 플러그인 핫 리로딩을 지원합니다.
**std::type_info::name()**는 구현 정의된 null 종료 바이트 문자열을 반환합니다. 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 없이는 이진 형식에는 필요한 형식 메타데이터가 존재하지 않습니다. 이러한 이유로 메타데이터의 생성에 대한 컴파일 타임 의존성 때문에, 컴파일러는 링킹 과정에서 오류(e.g., "undefined reference to typeinfo for 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 자체는 대부분의 표준 라이브러리 구현에서 비리터럴 또는 비구조적이므로, 컴파일 타임 상수가 요구되는 템플릿 인수로 사용될 수 없습니다.