1. Введение
Когда у вас появляется иерархия с виртуальными методами, мозг новичка иногда начинает играть в «угадайку»: «А вдруг мне надо узнать, какой именно объект лежит за IStorage*?». И вот тут на сцену выходит RTTI (Run-Time Type Information) — механизм, который позволяет во время выполнения получить информацию о динамическом типе объекта и попытаться безопасно привести базовый указатель к указателю на конкретного наследника.
Важно понимать настроение дня: RTTI — это не «плохо» и не «стыдно». Это инструмент. Просто он как огнетушитель: отлично, что он есть, но странно держать его включённым постоянно и жарить на нём яичницу. В архитектуре, где вы уже делаете полиморфизм, RTTI обычно сигналит: либо интерфейс не выражает нужное различие поведения, либо вы пытаетесь «вынести мозг» наружу вместо того, чтобы оформить его виртуальным методом.
Из RTTI в C++ нас интересуют два главных инструмента: dynamic_cast и typeid.
Статический тип и динамический тип
Прежде чем трогать dynamic_cast, нужно один раз (и надолго) «прошить» себе в голову разницу между статическим и динамическим типом. Иначе RTTI превращается в магию, а магия в программировании обычно заканчивается сообщением «Segmentation fault» и философским взглядом в стену.
Статический тип — это то, что написано в коде у переменной/параметра: IStorage*, Shape&, Base*. Динамический тип — это реальный тип объекта в памяти: FileStorage, Circle, Derived. Когда вы вызываете виртуальный метод через Base*, C++ выбирает реализацию по динамическому типу объекта.
Мини‑пример «на пальцах»:
#include <iostream>
struct Base {
virtual ~Base() = default;
virtual void ping() const { std::cout << "Base\n"; } // Base
};
struct Derived : Base {
void ping() const override { std::cout << "Derived\n"; } // Derived
};
int main() {
Derived d;
Base* p = &d; // статический тип p: Base*, динамический тип объекта: Derived
p->ping(); // Derived
}
Вот это расхождение «указатель Base*, а объект Derived» — нормальная жизнь полиморфизма. RTTI появляется, когда нам внезапно захотелось спросить: «а ты точно Derived?» — и что-то сделать по‑разному.
2. dynamic_cast: безопасная попытка «узнать наследника»
Когда вы держите объект за указатель/ссылку на базовый тип и хотите попробовать привести его к конкретному наследнику, dynamic_cast — официальный способ сделать это безопасно. В рамках этой лекции мы рассматриваем именно вариант с указателями, потому что он не требует обсуждать исключения и даёт очень простой контракт: «не получилось — будет nullptr».
Ключевое условие: базовый тип должен быть полиморфным, то есть иметь хотя бы одну виртуальную функцию. На практике это почти всегда виртуальный деструктор в интерфейсе, который мы и так обязаны делать: virtual ~I() = default.
Пример:
#include <iostream>
struct Shape {
virtual ~Shape() = default; // делает тип полиморфным
};
struct Circle : Shape {
int r = 10;
};
struct Square : Shape {
int a = 5;
};
void debug_print_shape(Shape* s) {
if (auto* c = dynamic_cast<Circle*>(s)) {
std::cout << "Circle r=" << c->r << "\n"; // Circle r=10
return;
}
if (auto* sq = dynamic_cast<Square*>(s)) {
std::cout << "Square a=" << sq->a << "\n"; // Square a=5
return;
}
std::cout << "Unknown shape\n"; // Unknown shape
}
Здесь важна дисциплина: мы проверяем результат на nullptr до разыменования. Это и есть «безопасность» dynamic_cast в варианте с указателем.
Почему цепочки dynamic_cast почти всегда симптом плохого интерфейса
Представьте, что вы написали так:
«Если это FileStorage, то делай одно, если MemoryStorage — другое, если NullStorage — третье…»
Проблема не в том, что оно «не работает». Проблема в том, что вы вручную реализуете диспетчеризацию по типу, вместо того чтобы выразить различие поведения через виртуальный метод интерфейса. Это приводит к двум типовым неприятностям.
Во‑первых, добавление нового наследника ломает код в неожиданных местах. Вы добавили CloudStorage, а потом выяснили, что нужно найти по проекту все места с dynamic_cast<FileStorage*> и дописать ещё одну ветку. То есть ваш «интерфейс» внезапно перестал быть интерфейсом: клиентский код снова знает про конкретные классы.
Во‑вторых, такая логика очень легко становится противоречивой: в одном месте забыли обработать новый тип, в другом обработали иначе, в третьем — по ошибке скопировали ветку.
Контраст с нормальным полиморфизмом выглядит так: вместо «угадывать тип» мы «просим объект сделать нужное». Если различие реально важно для поведения, оно должно быть выражено в интерфейсе виртуальным методом.
3. typeid: когда нужно имя типа
Иногда вам не нужно «привести» объект к наследнику. Вам нужно просто понять, что за штука прилетела, и вывести это в лог. Например, вы сделали фабрику, а затем хотите напечатать: «создан такой‑то storage». Вот тут уместен typeid.
typeid(expr) возвращает ссылку на объект std::type_info. Самое часто используемое — typeid(expr).name(). Но важно: name() — это не «красивое стабильное имя класса». Формат зависит от компилятора и настроек (часто он «заманглен»). Поэтому это годится для диагностики разработчика, но плохо подходит как «протокол» или ключ логики.
Показательный пример:
#include <iostream>
#include <typeinfo>
struct Base { virtual ~Base() = default; };
struct Derived : Base { };
int main() {
Derived d;
Base& b = d;
std::cout << typeid(b).name() << "\n"; // например: 7Derived (зависит от компилятора)
}
Почему здесь важно, что Base полиморфный? Потому что для полиморфных типов typeid через ссылку/разыменование учитывает динамический тип. В противном случае вы легко получите просто «Base», даже если внутри «Derived».
Отдельно отмечу (без погружения в исключения): попытки делать typeid(*p) при p == nullptr для полиморфного типа — плохая идея. Это как минимум аварийная ситуация для программы. Так что правило простое: прежде чем писать typeid(*p), убедитесь, что p не нулевой.
4. Пример: диагностируем, какой Storage создала фабрика
Давайте продолжим наш учебный мини‑проект — консольное приложение TaskPad, где задачи хранятся через абстракцию ITaskStorage. В прошлых лекциях у нас уже должна была появиться фабрика, которая создаёт реализацию по конфигу или CLI, и клиентский код работает через std::unique_ptr<ITaskStorage>.
Сделаем упрощённый интерфейс:
#include <string>
#include <string_view>
#include <vector>
struct Task {
int id = 0;
std::string title;
};
struct ITaskStorage {
virtual ~ITaskStorage() = default;
virtual void add(Task t) = 0;
virtual std::vector<Task> list() const = 0;
};
Дальше у нас есть реализации. Для лекции важна сама идея, поэтому реализации будут условными и короткими:
#include <utility>
#include <vector>
struct MemoryTaskStorage : ITaskStorage {
std::vector<Task> tasks;
void add(Task t) override { tasks.push_back(std::move(t)); }
std::vector<Task> list() const override { return tasks; }
};
И, допустим, файловая:
#include <string>
#include <utility>
#include <vector>
struct FileTaskStorage : ITaskStorage {
std::string path;
std::vector<Task> tasks;
explicit FileTaskStorage(std::string p) : path(std::move(p)) {}
void add(Task t) override { tasks.push_back(std::move(t)); }
std::vector<Task> list() const override { return tasks; }
};
Теперь представим, что у нас есть фабрика:
#include <memory>
#include <string>
#include <string_view>
enum class StorageKind { memory, file };
std::unique_ptr<ITaskStorage> make_storage(StorageKind kind, std::string_view arg) {
if (kind == StorageKind::file) {
return std::make_unique<FileTaskStorage>(std::string(arg));
}
return std::make_unique<MemoryTaskStorage>();
}
И вот нам захотелось сделать диагностическую печать: какой storage выбрали и, если он файловый, какой путь. Самый «в лоб» вариант — RTTI:
#include <iostream>
void debug_print_storage(const ITaskStorage& s) {
if (auto* fs = dynamic_cast<const FileTaskStorage*>(&s)) {
std::cout << "Storage: FileTaskStorage, path=" << fs->path << "\n";
return; // Storage: FileTaskStorage, path=tasks.txt
}
std::cout << "Storage: (non-file)\n"; // Storage: (non-file)
}
Почему это допустимо? Потому что это именно диагностическая функция. Она не принимает решений, не меняет алгоритм работы, не определяет бизнес‑правила. Она просто помогает разработчику увидеть «что создала фабрика». Это хороший пример «редкого и локального» RTTI.
5. Как сделать лучше: виртуальный метод для диагностики
Теперь сделаем следующий шаг зрелости. Мы понимаем, что хотим иногда печатать сведения о реализации — но не хотим, чтобы весь проект знал про FileTaskStorage. Значит, логичнее попросить объект самому уметь себя описывать через интерфейс.
Добавим в интерфейс метод debug_describe(...). Важно: мы заранее оговариваем, что это диагностическая штука, а не часть предметной логики. Контракт такой: метод не должен менять состояние (const) и должен печатать человекочитаемую строку.
#include <ostream>
struct ITaskStorage {
virtual ~ITaskStorage() = default;
virtual void add(Task t) = 0;
virtual std::vector<Task> list() const = 0;
virtual void debug_describe(std::ostream& out) const = 0;
};
Реализация в MemoryTaskStorage:
#include <ostream>
struct MemoryTaskStorage : ITaskStorage {
std::vector<Task> tasks;
void add(Task t) override { tasks.push_back(std::move(t)); }
std::vector<Task> list() const override { return tasks; }
void debug_describe(std::ostream& out) const override {
out << "MemoryTaskStorage, tasks=" << tasks.size() << "\n";
// MemoryTaskStorage, tasks=0
}
};
И в FileTaskStorage:
#include <ostream>
struct FileTaskStorage : ITaskStorage {
std::string path;
std::vector<Task> tasks;
explicit FileTaskStorage(std::string p) : path(std::move(p)) {}
void add(Task t) override { tasks.push_back(std::move(t)); }
std::vector<Task> list() const override { return tasks; }
void debug_describe(std::ostream& out) const override {
out << "FileTaskStorage, path=" << path << ", tasks=" << tasks.size() << "\n";
// FileTaskStorage, path=tasks.txt, tasks=0
}
};
Теперь клиентский код может сделать:
#include <iostream>
#include <memory>
int main() {
auto storage = make_storage(StorageKind::file, "tasks.txt");
storage->debug_describe(std::cout); // FileTaskStorage, path=tasks.txt, tasks=0
}
Заметьте, что здесь нам больше не нужен RTTI. Мы снова используем полиморфизм «как задумано»: поведение различается — значит, оно выражено виртуальным методом.
6. Когда RTTI уместен и как выбрать инструмент
Сейчас важно не впасть в другую крайность: «RTTI нельзя никогда». Можно. Но лучше, чтобы это было локально, осознанно и с понятной причиной.
RTTI бывает уместен в инфраструктурном коде: логирование, отладочные команды, диагностические дампы, статистика, телеметрия в dev‑сборках. Там вы часто не хотите расширять интерфейс «ради одного лога», потому что интерфейс — это контракт, который теперь должны реализовать все наследники.
Ещё RTTI может быть разумным мостом при интеграции с наследием. Например, у вас есть внешний API, который принимает именно ConcreteX*, а вы внутри держите I*. Тогда dynamic_cast превращается в «проверку совместимости»: если объект не тот — вы честно отказываетесь от операции или используете fallback.
Третий редкий случай — тесты или инструменты разработчика. Например, вы хотите убедиться, что фабрика по определённому конфигу создаёт именно FileTaskStorage. В прод‑коде это знание не нужно, но в тесте или диагностике — полезно.
dynamic_cast и typeid: мини‑таблица
| Инструмент | Что делает | Типичный результат | Когда уместно |
|---|---|---|---|
|
Пытается привести к наследнику безопасно | |
Когда нужно попробовать использовать специфичный API наследника локально (обычно диагностика или интеграции) |
|
Получает информацию о типе выражения во время выполнения | |
Для логов и диагностики «что это за объект вообще» |
И ещё одна микро‑схема, как это обычно выглядит в проекте:
flowchart TD
A[Есть ITaskStorage&] --> B{Нужно поведение?}
B -->|Да| C[Добавить или использовать virtual метод в интерфейсе]
B -->|Нет, только диагностика| D{Нужен доступ к полям наследника?}
D -->|Да| E[dynamic_cast + проверка nullptr]
D -->|Нет, просто имя| F["typeid(...) для лога"]
Да, это «схема здравого смысла», а не математическое доказательство. Но в реальном коде здравый смысл — очень конкурентоспособная технология.
7. Типичные ошибки при работе с RTTI
Ошибка №1: использовать RTTI как основной механизм ветвления логики.
Очень легко написать «если это A — делаем так, если B — иначе…», и поначалу кажется, что вы молодец: всё под контролем. Но вы фактически отменяете полиморфизм и заставляете клиентский код знать все реализации. Через пару итераций это превращается в боль при добавлении новых типов. Если различие влияет на поведение, оно должно быть выражено виртуальным методом интерфейса.
Ошибка №2: забыть, что dynamic_cast требует полиморфную базу.
dynamic_cast работает по RTTI‑метаданным, которые появляются только у полиморфных типов. Если в базовом классе нет виртуальных функций, приведение либо не компилируется, либо не имеет смысла. Хорошая привычка: у интерфейса всегда есть virtual ~I() = default, и это автоматически делает базу полиморфной.
Ошибка №3: разыменовать результат dynamic_cast, не проверив nullptr.
Вариант с указателем специально удобен тем, что при неуспехе вы получаете nullptr. Но если после dynamic_cast сразу написать p->field, то вы получаете классическую аварию. Правило простое: сначала if (auto* d = dynamic_cast<...>(p)), потом используем.
Ошибка №4: использовать typeid(...).name() как стабильный идентификатор.
Новички иногда начинают сравнивать строки: if (typeid(x).name() == "FileTaskStorage"). Это крайне ненадёжно: формат зависит от компилятора и может быть заманглен. name() годится для вывода в лог «для человека», но плохо годится как часть логики программы.
Ошибка №5: тянуть RTTI через весь проект вместо локальной диагностической функции.
Самый здоровый сценарий RTTI — маленькая функция в одном месте (например, debug_print_storage), которая не влияет на основную работу приложения. Если dynamic_cast начинает встречаться в «боевых» функциях (парсинг, выполнение команд, расчёты), это почти всегда сигнал, что интерфейс не описывает нужное поведение или что обязанности перепутаны.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ