std::type_index, bir std::type_info nesnesine işaretçi kapsüllleyerek ve karşılaştırmayı temel before() üye fonksiyonuna devrederek, çeviri birimi arası sıralama sağlar. C++ ABI'si, bağlantıcının, aynı türler için çeviri birimleri arasında tür bilgilerini tek bir kanonik nesneye birleştirmesini gerektirir (COMDAT bölümleri veya zayıf semboller kullanarak) veya before()'un fiziksel adres farklılıklarından bağımsız olarak tutarlı bir toplam sıralama sağlamasını garanti eder. Sonuç olarak, std::type_index, bu ABI-garantili karşılaştırmayı sarmalayarak, karşılaştırma noktası itibarıyla türlerin tam olmasını gerektirmeden operator< ve hash desteği sağlar. Bu mekanizma tamamen çalışma zamanı tür bilgisine (RTTI) dayanır, çünkü derleyicinin tür meta verilerini üretmesi gerekir, bu da bağlantıcının paylaşılan kütüphane sınırları boyunca tür kimliklerini birleştirmesine veya ayırmasına olanak tanır.
Bir oyun motoru için bir eklenti mimarisi tasarlarken, bileşen türlerini fabrika fonksiyonlarına eşleyen merkezi bir kayıt defteri oluşturmamız gerekiyordu. Her eklenti (paylaşılan kütüphane), bileşenlerini anahtar olarak typeid(Component).name() kullanarak kaydetti. Ancak, çapraz platform testleri sırasında, bir paylaşılan kütüphaneye yüklenen bir eklentinin, başka bir paylaşılan kütüphanede bulunan temel motor tarafından kaydedilen bir fabrikayı almakta aralıklı olarak başarısız olduğunu keşfettik. Temel neden, type_info::name() tarafından döndürülen dize adlarının derleyiciler arasında (GCC ile Clang) farklılık göstermesiydi ve type_info nesnelerinin doğrudan işaretçi karşılaştırması, her paylaşılan kütüphanenin aynı türler için farklı statik örnekler içermesi nedeniyle başarısız oldu.
Çözüm 1: Manuel dize normalizasyonu
Dize adlarını insan tarafından okunabilir anahtarlar oluşturmak için abi::__cxa_demangle gibi derleyiciye özgü API'leri kullanarak dönüştürmeyi ve normalleştirmeyi düşündük. Bu yaklaşım, hata ayıklama için uygun insan tarafından okunabilir tanımlayıcılar vaat etti.
Artıları: İnsan tarafından okunabilir anahtarlar, günlüğe kaydetmeyi ve seri hale getirmeyi kolaylaştırır.
Eksileri: Dönüştürme pahalıdır, dize karşılaştırması tam sayı karşılaştırmasından daha yavaştır ve formatın uygulamaya bağlı kalması, gelecekteki derleyici güncellemeleriyle kaydın kırılma riskini taşır.
Çözüm 2: Sanal miras ve özel RTTI
Tüm bileşenlerin manuel olarak atanmış bir tamsayı sabitini döndüren sanal bir GetTypeID() yöntemine sahip bir temel sınıftan miras almasını talep etmeyi araştırdık.
Artıları: Deterministik, hızlı tamsayı karşılaştırmaları ve derleyici RTTI'ye bağımlılık yoktur.
Eksileri: Manuel ID atanması hata yapmaya açıktır (çakışmalar), sınıf hiyerarşilerini değiştirmeyi gerektirir ve kontrolümüz altındaki üçüncü taraf türlerini ele alamaz.
Çözüm 3: std::type_index'in benimsenmesi
Kayıt defterini std::map<std::type_index, FactoryFunc> olarak kullanacak şekilde yeniden yapılandırdık ve anahtar olarak std::type_index(typeid(T)) kullandık.
Artıları: Standart, ABI'ye uygun type_info karşılaştırması yoluyla çeviri birimleri arasında tutarlı sıralama ve hash garantisi verir, manuel ID yönetimi gerektirmez ve typeid ile mevcut kodla sorunsuz bir şekilde entegre olur.
Eksileri: RTTI'nin etkinleştirilmesi gereklidir (ikili boyutu artırır) ve type_index nesneleri ağ iletimi veya kalıcı depolama için seri hale getirilemez.
Çözüm 3'ü seçtik çünkü kütüphaneler arası tür kimliği belirlemenin güvenilirliği, RTTI'nin ikili boyut maliyetine ağır bastı. std::type_index'in standart tarafından zorunlu tutulan davranışı, alternatiflerin başına gelen kırılgan dize ayrıştırma ve manuel ID bakımı sorunlarını ortadan kaldırdı.
Kayıt defteri Linux, Windows ve macOS'ta DLL sınırları boyunca düzgün çalıştı. Fabrika aramaları artık O(log N) içsel işaretçi karşılaştırmaları haline geldi ve dize işlemleri yerine yaklaşık %40 oranında bileşen oluşturma gecikmesini azalttı. Sistem artık temel motor türlerinin yeniden kaydedilmesine gerek kalmadan eklentilerin sıcak yeniden yüklenmesini destekliyor.
std::type_info::name(), uygulamaya bağlı bir null-terminasyonlu bayt dizisi döndürür; C++ standardı formatını, kodlamasını veya kararlılığını kesin bir şekilde belirtmekten açıkça kaçınır. Örneğin, GCC tipik olarak karışık adlar döndürür (örneğin, "St6vectorIiSaIiEE"), MSVC ise insan tarafından okunabilir adlar döndürür (örneğin, "class std::vector<int,class std::allocator<int> >"). Derleyici satıcıları, hata ayıklama iyileştirmeleri veya sembol uzunluklarını azaltmak amacıyla bu temsilleri gelecekteki sürümlerde değiştirebilir. Sonuç olarak, bu dizelerin diske veya ağ protokollerine seri hale getirilmesi, derleyici güncellemeleri sırasında belirsiz davranışlar yaratır, çünkü daha önce kaydedilen anahtarlar yenilikle oluşturulanlarla artık eşleşmeyecektir. Adaylar genellikle name()'in kararlı bir UUID gibi davrandığını varsayıyorlar.
RTTI devre dışı bırakıldığında, derleyici, polimorfik türler için type_info nesneleri üretmez ve typeid operatörü hatalı olur (statik tür ifadeleri dışında, bazı uygulamalarda statik tür bilgisi döndürülür, ancak genel olarak devre dışı bırakılır). std::type_index, yapılandırılması için const std::type_info& gerektirir ve RTTI olmadan gerekli tür meta verisi ikili dosyada mevcut değildir. Çünkü bu, üretilen meta veriye olan derleme zamanı bağımlılığıdır, derleyici, bağlantı sırasında bir hata (örneğin, "X için typeinfo'ya tanımsız referans") çıkarır, bunun yerine yakalanabilir bir çalışma zamanı istisnasına devretmektense. Adaylar genellikle bir çalışma zamanı std::bad_typeid veya benzeri bir beklediklerini varsayıyor, bunu dynamic_cast hatalarıyla karıştırıyorlar.
std::type_index, dahili olarak bir std::type_info nesnesine işaretçi (veya referans) depolar. C++20 ve daha önceki sürümlerde non-type template parametreleri, tüm üyeleri kamuya açık olan ve yapısal türler (veya bunların dizileri) gerektirir ve dinamik depolama veya bağlantıya bağlı adresler ile nesneleri içeremezler. type_info nesneleri statik depolama alanlarında ve bağlantı bağımlı adreslerde bulunduğundan, ve std::type_index yapısal bir tür olmadığından (bazı uygulamalarda özel üyeler ve karmaşık bir kopya konstrüktörü vardır), NTTP olarak kullanılamaz. C++23, typeid'i sabit ifadelerde kullanmaya izin verse de, std::type_index kendisi çoğu standart kütüphane uygulamasında literel veya yapısal değildir, bu da derleme zamanı sabitlerinin gerekli olduğu şablon argümanlarında kullanılmasını engeller.