Жизнеспособные примеры C++ RTTI

Ациклический посетитель (pdf) отлично его использует.

Я не могу сказать, что когда-либо находил применение в реальной жизни, но RTTI упоминается в Эффективный C++ как возможное решение для нескольких методов в C++. Это связано с тем, что диспетчеризация метода выполняется для динамического типа параметра this, но для статического типа аргументов.

class base
{
  void foo(base *b) = 0; // dynamic on the parameter type as well
};

class B : public base {...}
class B1 : public B {...}
class B2 : public B {...}

class A : public base
{
  void foo(base *b)
  {
    if (B1 *b1=dynamic_cast<B1*>(b))
      doFoo(b1);
    else if (B2 *b2=dynamic_cast<B2*>(b))
      doFoo(b2);
  }
};

Однажды я работал над симулятором самолета, который имел то, что они (несколько сбивчиво) называли «Базой данных симуляции». Вы можете регистрировать в нем такие переменные, как числа с плавающей запятой, целые числа или строки, и люди могут искать их по имени и извлекать ссылку на них. Вы также можете зарегистрировать модель (объект класса, производного от «SimModel»). Я использовал RTTI, чтобы вы могли искать модели, реализующие данный интерфейс:

SimModel* SimDatabase::FindModel<type*>(char* name = "")
{
   foreach(SimModel* mo in ModelList)
   if (name == "" || mo->name eq name)
   {
       if (dynamic_cast<type*>mo != NULL)
       {
           return dynamic_cast<type*>mo;
       }
   }
   return NULL;
}

Базовый класс SimModel:

class public SimModel
{
    public:
        void RunModel()=0;
};

Примером интерфейса может быть "EngineModel":

class EngineModelInterface : public SimModel
{
    public:
        float RPM()=0;
        float FuelFlow()=0;
        void SetThrottle(float setting)=0; 
};

Теперь, чтобы сделать двигатель Lycoming и Continental:

class LycomingIO540 : public EngineModelInterface 
{
    public:
        float RPM()
        {
            return rpm;
        }
        float FuelFlow()
        {
            return throttleSetting * 10.0;
        }
        void SetThrottle(float setting) 
        {
            throttleSetting = setting
        }
        void RunModel() // from SimModel base class
        {
            if (throttleSetting > 0.5)
                rpm += 1;
            else
                rpm -= 1;
        }
    private:
        float rpm, throttleSetting;
};
class Continental350: public EngineModelInterface 
{
    public:
        float RPM()
        {
            return rand();
        }
        float FuelFlow()
        {
            return rand;
        }
        void SetThrottle(float setting) 
        {
        }
        void RunModel() // from SimModel base class
        {
        }
};

А теперь вот код, в котором кому-то нужен двигатель:

.
.
EngineModelInterface * eng = simDB.FindModel<EngineModelInterface *>();
.
.
fuel = fuel - deltaTime * eng->FuelFlow();    
.
.
.

Код довольно псевдо, но я надеюсь, что он передаёт идею. Один разработчик может написать код, который зависит от наличия движка, но пока в нем есть что-то, реализующее интерфейс движка, ему все равно, что это такое. Таким образом, код, который обновляет количество топлива в баках, полностью отделен от всего, кроме функции FindModel <> () и чистого виртуального интерфейса EngineModel, который ему интересно использовать. Кто-нибудь через год может создать новую модель двигателя, зарегистрировать ее в SimulationDatabase, и тот парень, который обновляет топливо, начнет использовать ее автоматически. На самом деле я сделал это так, чтобы вы могли загружать новые модели в виде плагинов (DLL) во время выполнения, и после того, как они были зарегистрированы в SimulationDatabase, их можно было найти с помощью FindModel <> (), даже если код, который их искал, был скомпилирован и встроен в DLL за несколько месяцев до появления новой DLL. Вы также можете добавить новые интерфейсы, производные от SimModel, с чем-то, что реализует их в одной DLL, что-то, что ищет их в другой DLL, и после загрузки обеих DLL можно выполнить FindModel <> (), чтобы получить модель в другой. Хотя самого интерфейса даже не существовало, когда было создано основное приложение.

В скобках RTTI не всегда работает за пределами DLL. Так как я все равно использовал Qt, я использовал qobject_cast вместо dynamic_cast. Каждый класс должен был унаследовать от QObject (и получить moc'd), но метаданные qobject всегда были доступны. Если вам не нужны библиотеки DLL или вы используете цепочку инструментов, в которой RTTI делает работает через границы DLL (сравнение типов на основе сравнения строк вместо хешей или чего-то еще), тогда все вышеперечисленное с dynamic_cast будет работать нормально.

Несколько лет назад я использовал RTTI при работе с Qt на основе холста. При выполнении тестов на попадание объектов было чертовски удобно использовать RTTI, чтобы определить, что я собираюсь делать с формой, которую я «поразил». Но я не использовал его иначе в производственном коде.

Как насчет повышения :: любого объекта!

Это в основном использует информацию RTTI для хранения любого объекта, а для извлечения этого объекта используется boost :: any_cast <>.

Вы можете использовать RTTI с dynamic_cast, чтобы получить указатель на производный класс, чтобы использовать его для вызова быстрого специализированного алгоритма типа. И вместо использования виртуальных методов через базовый класс он будет делать прямые и встроенные вызовы.

Это сильно ускорило работу с GCC. Visual Studio, похоже, тоже не справилась, у нее может быть более медленный поиск dynamic_cast.

Пример:

D* obj = dynamic_cast<D*>(base);
if (obj) {
    for(unsigned i=0; i<1000; ++i)
        f(obj->D::key(i));
    }
} else {
    for(unsigned i=0; i<1000; ++i)
        f(base->key(i));
    }
}

Я использую его в дереве классов, которое сериализуется в файл XML. При десериализации класс анализатора возвращает указатель на базовый класс, который имеет перечисление для типа подкласса (потому что вы не знаете, какой это тип, пока не проанализируете его). Если код, использующий объект, должен ссылаться на определенные элементы подкласса, он включает значение enum и dynamic_cast для подкласса (который был создан синтаксическим анализатором). Таким образом, код может проверить, что синтаксический анализатор не обнаружил ошибки и несоответствия между значением перечисления и возвращенным типом экземпляра класса. Виртуальных функций также недостаточно, потому что у вас могут быть данные конкретного подкласса, к которым вам нужно добраться.

Это всего лишь один пример того, где может быть полезен RTTI; Возможно, это не самый элегантный способ решения проблемы, но использование RTTI делает приложение более надежным при использовании этого шаблона.

Использую с Dynamic Double Dispatch и шаблоны. По сути, это дает возможность наблюдать / слушать только интересные части объекта.

Иногда приводов static_cast и C-стиля просто недостаточно, и вам нужен dynamic_cast, например, когда у вас есть ужасный ромбовидная иерархия (изображение из Википедии).

struct top {
};

struct left : top { 
    int i;
    left() : i(42) {}
};

struct right : top {
    std::string name;
    right() : name("plonk") { }
};

struct bottom : left, right {
};

bottom b;
left* p = &b;

//right* r = static_cast<right*>(p); // Compilation error!
//right* r = (right*)p;              // Gives bad pointer silently 
right* r = dynamic_cast<right*>(p);  // OK

Примеры использования, которые у меня есть в моих проектах (если вы знаете лучшее решение для конкретных случаев, прокомментируйте):

1. То же, что уже упоминалось 1800 ИНФОРМАЦИЯ:

   Вам понадобится dynamic_cast для реализации operator== или operator< для производных классов. По крайней мере, я не знаю другого пути.

2. Если вы хотите реализовать что-то вроде boost::any или другого варианта контейнера.

3. В одной игре из класса Client, в которой был std::set<Player*> (возможные экземпляры - NetPlayer и LocalPlayer) (в котором могло быть не более одного LocalPlayer), мне нужна была функция LocalPlayer* Client::localPlayer(). Эта функция используется очень редко, поэтому я не хотел загромождать Client дополнительной локальной переменной-членом и всем дополнительным кодом для ее обработки.

4. У меня есть абстрактный класс Variable с несколькими реализациями. Все зарегистрированные Variable находятся в некоторых std::set<Variable*> vars. И есть несколько встроенных переменных типа BuiltinVar, которые сохранены в std::vector<BuiltinVar> builtins. В некоторых случаях у меня есть Variable*, и мне нужно проверить, является ли он BuiltinVar* и внутри builtins. Я мог бы сделать это либо с помощью некоторой проверки диапазона памяти, либо с помощью dynamic_cast (в любом случае я могу быть уверен, что все экземпляры BuiltinVar находятся в этом векторе).

5. У меня есть коллекция GameObject с сеткой, и мне нужно проверить, есть ли объект Player (специализированный GameObject) внутри одной сетки. У меня могла бы быть функция bool GameObject::isPlayer(), которая всегда возвращает false, кроме Player, или я мог бы использовать RTTI. Есть еще много подобных примеров, когда люди часто реализуют такие функции, как Object::isOfTypeXY(), и из-за этого базовый класс становится очень загроможденным.

   Иногда то же самое и с другими очень специальными функциями, такими как Object::checkScore_doThisActionOnlyIfIAmAPlayer(). Есть некоторый здравый смысл, необходимый, чтобы решить, когда действительно имеет смысл иметь такую ​​функцию в базовом классе, а когда нет.

6. Иногда я использую его для утверждений или проверок безопасности во время выполнения.

7. Иногда мне нужно сохранить указатель некоторых данных в каком-либо поле данных какой-либо библиотеки C (например, SDL или что-то еще), и я получаю его позже в другом месте или в качестве обратного вызова. Я делаю здесь dynamic_cast, чтобы убедиться, что получаю то, что ожидаю.

8. У меня есть класс TaskManager, который выполняет некоторую очередь Task. Для некоторых Task, когда я добавляю их в список, я хочу удалить из очереди другие Task того же типа.