RTTI w C++

Analiza run-time type information (RTTI) w języku C++

Run-time type information (RTTI) to fundamentalny mechanizm C++, umożliwiający dynamiczną identyfikację typu w trakcie wykonywania programu. RTTI zostało wprowadzone, by ujednolicić różne, konkurencyjne implementacje vendorów oraz rozwiązać problemy niekompatybilności bibliotek. RTTI obejmuje trzy podstawowe elementy języka: operator dynamic_cast do bezpiecznych konwersji polimorficznych, operator typeid do identyfikacji typu w czasie działania oraz klasę type_info, przechowującą metadane o typie. System ten dostępny jest wyłącznie dla klas polimorficznych – takich, które zawierają co najmniej jedną funkcję wirtualną, ponieważ polega na tablicach wirtualnych (vtable). Mimo że RTTI umożliwia elastyczne wzorce obiektowe (jak bezpieczne zrzutowania w dół i dynamiczne sprawdzania typów), wiąże się z mierzalnym narzutem pamięci (ok. 1MB dla jvm.dll pod Windows) i konsekwencjami wydajnościowymi, dlatego w środowiskach wbudowanych bądź wysokowydajnych bywa wyłączane poprzez flagi takie jak -fno-rtti (GCC/Clang) czy /GR- (MSVC). Alternatywnymi rozwiązaniami są ręczne typy enum oraz wzorce odwiedzające, choć wymagają one znacznej ilości kodu szablonowego. W kolejnych sekcjach omawiane są mechanizmy RTTI, implementacje w różnych kompilatorach, strategie optymalizacji oraz praktyczne przypadki zastosowań.

Kontekst historyczny i standaryzacja

Mechanizmy RTTI pojawiły się jako oficjalne rozwiązanie fragmentacji wcześniejszych prób introspekcji typów w C++. W latach 80. różni producenci bibliotek klas wdrażali własne systemy sprawdzania typu, co prowadziło do braku zgodności między kodami. Bjarne Stroustrup początkowo pominął RTTI, obawiając się nadużyć, lecz narastające problemy interoperacyjności wymusiły oficjalną standaryzację. ISO C++98 sformalizowało RTTI poprzez dynamic_cast, typeid i type_info, tworząc jednolite ABI (Application Binary Interface) dla implementacji kompilatorów. Ustandaryzowanie tych mechanizmów okazało się kluczowe przy dużych projektach łączących biblioteki od różnych dostawców, ponieważ RTTI dawało językową gwarancję spójnego zarządzania typami.

Microsoft w swojej dokumentacji stwierdza: „RTTI zostało wprowadzone, ponieważ wielu dostawców bibliotek klas implementowało tę funkcjonalność samodzielnie, co powodowało niekompatybilności między bibliotekami”. Konstrukcja RTTI ogranicza jego aktywację wyłącznie do typów polimorficznych, minimalizując nadmiarowe metadane dla prostych hierarchii.

Podstawowe mechanizmy RTTI

Operator dynamic_cast

Operator dynamic_cast służy do bezpiecznego zrzutowania w dół w hierarchiach dziedziczenia. W przeciwieństwie do rzutowań w stylu C lub static_cast, sprawdza poprawność konwersji w czasie działania według poniższego schematu:

1. Walidacja wskaźnika – sprawdza, czy wskaźnik źródłowy odnosi się do kompletnego obiektu docelowego typu;
2. Obsługa cross-cast – dostosowuje adresy wskaźnika przy rzutowaniach między równoległymi gałęziami dziedziczenia;
3. Obsługa niepowodzenia – zwraca nullptr (dla wskaźników) lub rzuca std::bad_cast (dla referencji) przy niepoprawnych konwersjach.

Base* b = new Derived();
Derived* d = dynamic_cast<Derived*>(b); // Poprawna konwersja
if (d) { /* ścieżka sukcesu */ }

Ten mechanizm zapobiega niezdefiniowanym zachowaniom przy rzutowaniach między niepowiązanymi typami. W MSVC dynamic_cast korzysta ze struktur RTTICompleteObjectLocator, połączonych z vtable, aby odtworzyć układ obiektów przy cross-castach. Wydajność zależy od głębokości hierarchii; np. GCC optymalizuje sprawdzania za pomocą haszowania typów.

System identyfikacji typu

Operator typeid zwraca const std::type_info& zawierający metadane typu. Główne cechy:

• Ciąg nazwy – dostępny przez name(), zwracający zależną od implementacji, czytelną nazwę (np. „class Derived”);
• Porównywanie typów – przeciążone operatory == i != umożliwiają bezpośrednie sprawdzanie zgodności typów;
• Kolejność sortowania – before() pozwala porównywać typy względem siebie, aczkolwiek kolejność jest specyficzna dla kompilatora.

if (typeid(*obj) == typeid(Derived)) {
// logika specyficzna dla Derived
}

typeid ignoruje kwalifikatory const/volatile na poziomie najwyższym, lecz rozróżnia referencje (typeid(int&) ≠ typeid(int)). W kontekście polimorficznym zwraca typ dynamiczny, w pozostałych wypadkach typ statyczny.

Klasa type_info

Klasa type_info (<typeinfo>) przechowuje metadane RTTI, z następującymi szczegółami:

• Niekopiowalność – skasowany konstruktor kopiujący/operator przypisania zapobiega kopiowaniu;
• Nazwy zakodowane – raw_name() zwraca dekorowane identyfikatory (np. .?AVDerived@@) dla efektywnej reprezentacji nazwy;
• Obsługa hashy – hash_code() umożliwia użycie w kontenerach asocjacyjnych.

Kompilatory umieszczają wskaźniki do type_info w vtable, zazwyczaj pod stałym offsetem (przykładowo -8 bajtów w MSVC x64). To rozwiązanie nie powiększa każdego obiektu, ale skutkuje wzrostem rozmiaru binarnego dla każdej klasy polimorficznej poprzez rozwinięcie vtable.

Strategie implementacyjne kompilatorów

Zintegrowanie z vtable

Wiodące kompilatory (GCC, Clang, MSVC) implementują RTTI przez vtable. Dla każdej klasy polimorficznej kompilator:

1. Generuje vtable – zawiera wskaźniki funkcji wirtualnych i sloty metadanych;
2. Umieszcza type_info* – osadza wskaźnik do statycznego type_info w ujemnym indeksie vtable;
3. Dodaje struktury RTTI – generuje RTTICompleteObjectLocator (w MSVC) bądź równoważne elementy śledzące dziedziczenie.

Dla MSVC układ pamięci klasy Derived dziedziczącej z Base1 i Base2 wygląda następująco:

VTable (Base1):
 0: VirtualFunc1
-1: RTTICompleteObjectLocator*
VTable (Base2):
 0: VirtualFunc2
-1: thunk dostosowujący this
-2: RTTICompleteObjectLocator*

Cross-casty (Base2* → Derived*) wykorzystują RTTICompleteObjectLocator do obliczeń adresacyjnych. GCC i Clang stosują podejście analogiczne, lecz używają własnych struktur (np. vtable for Derived).

Narzut pamięciowy i wydajnościowy

RTTI powoduje dwa główne narzuty:

1. Rozmiar binarny – każda polimorficzna klasa powiększa się o ok. 32 bajty metadanych type_info i struktur lokalizacyjnych. Wyłączenie RTTI redukuje jvm.dll w OpenJDK o ok. 1MB;
2. Koszty w trakcie działania – dynamic_cast przeszukuje graf dziedziczenia – złożoność O(n) przy n klasach bazowych. Benchmarki wykazują spadki wydajności o 5–20% dla głębokich hierarchii.

Systemy wbudowane (np. ARM Cortex-M) często wyłączają RTTI przez -fno-rtti, oszczędzając ok. 10KB firmware. Alternatywy, jak cechy typów w czasie kompilacji (std::is_base_of), nie powodują tego narzutu, lecz brak im dynamicznej elastyczności.

Wyłączanie RTTI – motywacje i alternatywy

Przykłady optymalizacyjne

Wyłączenie RTTI stosuje się najczęściej w projektach, które priorytetowo traktują:

• Środowiska o ograniczonej pamięci – urządzenia IoT o pamięci <100KB RAM;
• Kod o krytycznych wymaganiach wydajnościowych – np. systemy transakcji wysokiej częstotliwości lub systemy czasu rzeczywistego;
• Minimalizację rozmiaru binarnego – np. konsole gier wymagające minimalnych plików wykonywalnych.

Przykładowo, w projekcie OpenJDK Microsoftu wyłączenie RTTI dla Hotspot JVM umożliwiło zredukowanie jvm.dll o 1MB bez utraty funkcjonalności. Podobnie, nagie profile GCC domyślnie włączają -fno-rtti dla targetów embedded.

Techniczne alternatywy

1. Ręczne znaczniki typów –

   
   class Shape {
     public:
       enum Type { Circle, Rectangle };
       Type type;
       Shape(Type t) : type(t) {}
   };
   

   Zalety: brak narzutu. Wady: brak bezpieczeństwa dziedziczenia;

2. Wzorzec odwiedzający –

   
   class Visitor {
     virtual void Visit(Circle&) = 0;
     virtual void Visit(Rectangle&) = 0;
   };
   

   Zalety: typowane dynamiczne wywołania. Wady: nadmiar szablonu; sztywna architektura;

3. Własne systemy RTTI –

   
   struct TypeInfo {
     string name;
     vector<TypeInfo*> bases;
   };
   

   Zalety: kompatybilność cross-DLL. Wady: złożoność ponownej implementacji.

Zwraca uwagę, że przewodnik stylu Google C++ zakazuje używania RTTI z powodu narzutu binarnego, promując alternatywne rozwiązania.

Praktyczne zastosowania i przykłady

Bezpieczne przetwarzanie polimorficzne

RTTI umożliwia typowane obsługi kolekcji heterogenicznych:

vector<unique_ptr<Animal>> zoo;
zoo.push_back(make_unique<Lion>());

for (auto& animal : zoo) {
  if (auto lion = dynamic_cast<Lion*>(animal.get())) {
    lion->roar(); // zachowanie charakterystyczne dla Lion
  }
}

Unika się niezdefiniowanego zachowania przy zrzutowaniach w dół. Bez dynamic_cast ręczna kontrola typu staje się bardzo podatna na błędy przy głębokich hierarchiach.

Walidacja wzorca fabryki

RTTI zabezpiecza przed niepoprawnym tworzeniem obiektów:

class Factory {
  template <typename T>
  T* create() {
    static_assert(is_base_of<Base, T>::value, "Niepoprawny typ fabryki");
    return new T();
  }
};

W połączeniu z typeid zapewnia to kontrolę typów w czasie działania.

Debugowanie i serializacja

type_info::name() ułatwia debugowanie:

void debugPrint(Base* obj) {
  cout << "Przetwarzanie " << typeid(*obj).name();
}

Systemy serializacji (np. Boost.Serialization) wykorzystują RTTI do wersjonowania i obsługi metadanych typów.

Analiza porównawcza – inne języki

C++ stawia na „zero kosztów” – RTTI aktywuje się jedynie przy konkretnym użyciu, w przeciwieństwie do Java/C#, gdzie każdy obiekt posiada metadane typu. Python oraz JavaScript oferują jeszcze bogatszą introspekcję, jednak kosztem większych narzutów środowiska wykonawczego.

• Object Pascal – operator as naśladuje dynamic_cast; is zbliżony do typeid,
• Ada – typy tagowane przechowują metainformacje dostępne przez operator in,
• Rust – jawne dyn Trait z Any::type_id() dla ograniczonej refleksji.

W C++ metadane przechowywane są w vtable, nie w każdym obiekcie – ograniczając uniwersalny narzut pamięci.

Dobre praktyki i wskazówki

Zalecane zastosowania

1. Narzędzia debugujące – diagnostyka typów w logerach i inspektorach;
2. Pojemniki heterogeniczne – bezpieczna obsługa elementów w vector<Base*>;
3. Podwójna dyspozycja – w połączeniu ze wzorcem odwiedzającego dla polimorfizmu zdarzeń;
4. Architektury pluginów – dynamiczne ładowanie modułów z kontrolą typu interfejsu.

Antywzorce do unikania

• Przełączniki po typach –

  
  if (typeid(t) == typeid(A)) {…}
  else if (typeid(t) == typeid(B)) {…} // zamiast tego preferuj funkcje wirtualne
  

  Łamie zasadę Open/Closed; utrudnia rozszerzalność;

• Nieograniczone zrzutowania w dół –

  
  auto b = dynamic_cast<Derived*>(untrusted_ptr);
  if (!b) throw … // preferuj referencje przy obowiązkowych typach
  

  Stosuj referencje, gdy błędne rzutowanie powinno być wyjątkowe;

• RTTI bez polimorfizmu –

  
  struct NonPoly {};
  typeid(NonPoly); // zwraca wyłącznie typ statyczny
  

  Daje gwarantowane zachowanie statyczne – zamiast tego korzystaj z cech typów.

Kierunki rozwoju i optymalizacja

Innowacje kompilatorów

• Selektywne RTTI – propozycje atrybutów per-klasa (np. [[rtti]]), by ograniczyć metadane;
• Rzutowania bazujące na haszach – dynamic_cast w GCC wykorzystuje cache z haszami dla O(1) porównań w pojedynczym dziedziczeniu;
• Optymalizacja przy linkowaniu – eliminacja martwego RTTI podczas linkowania zmniejsza metadane.

Standaryzacja w przyszłości

C++26 może przynieść:

• Własne providery RTTI – możliwość użytkowego zastąpienia type_info;
• Integrację Reflection TS – unifikacja składniowa z cechami refleksji statycznej.

Podsumowanie

Run-time type information pozostaje niezbędnym elementem bezpiecznego polimorfizmu w C++, łącząc elastyczność z przewidywalnym narzutem. Konstrukcja RTTI – ograniczona do typów polimorficznych i zarządzana przez kompilator – odzwierciedla filozofię „płacisz tylko za to, z czego korzystasz”. Choć alternatywy jak ręczne znaczniki typów czy wzorzec odwiedzającego sprawdzają się w środowiskach z ograniczeniami, to RTTI oferuje bezkonkurencyjną gwarancję poprawności dla dynamicznych rzutowań i rozpoznawania typu. Perspektywy rozwoju obejmują aktywację z precyzją per-klasa oraz integrację z refleksją, zapewniając trwałą przydatność RTTI w nowoczesnym C++. Szczególnie powinniśmy korzystać z RTTI wszędzie tam, gdzie bezpieczeństwo czasu wykonania uzasadnia jego koszt – w pozostałych przypadkach lepiej stawiać na polimorfizm statyczny.