Определение структуры

[_Bers]

Сообщение от waleri

Уф
class CParent;
class CChild : public CParent;
CParent* ptr = new CChild;
CChild* crash = dynamic_cast<CChild*>(ptr);
typeid(ptr) == ?

Пример не корректный. Нельзя наследоваться от неполных типов.

А что касается динамик_каста: его нельзя использовать для не_полиморфных типов. Что замечательно вычисляется времени компиляции:

struct Base{};
struct Derive1: Base {};
void Foo(Base* ptr){ cout<< typeid(*ptr).name()<<endl; }

int main()
{
    Base* _ptr = new Derive1();
    
    //: error C2683: dynamic_cast: "Base" не является полиморфным типом
    //Derive1* ptr1 = dynamic_cast<Derive1*>(_ptr);
   
    Foo(_ptr); //вывод: struct Base
    
    return 0;
}

Добавь в базу хоть один виртуальный метод, и тут же заработает RTTI

[waleri]

Ну что же, соглашусь. Признаюсь, RTTI избегаю как огня и соответно не знаю тонкостей.

[_Bers]

Сообщение от waleri

Ну что же, соглашусь. Признаюсь, RTTI избегаю как огня и соответно не знаю тонкостей.

Ну я тоже избегаю. Считаю его присутствие в своем коде "исключительно костыльным решением, продиктованным несовершенством мира".

Хотя я не вижу ничего плохого в статик_тайп_ид. Оно же уже не кушает время в рантайме.

А фокус тут следующий: Предположим, есть полиморфная иерархия.
У потомка создаётся уникальный айдишник (привязка к параметру шаблона, ну или тупо к какому нибудь енуму).

В интерфейсе базы есть метод

virtual const type_info& GetTypeInfo()=0;

А потомок создает тупо тайпдеф:

//где то в объявлении класса
typedef RTTI<T> RTTI_t;

ну или оно же, ток от енума.

И реализует интерфейсный метод:

virtual const type_info& GetTypeInfo()const { return typedeid(RTTI_t); }

Таким образом, полиморфный потомок возвращает свой как бы ид, который вычисляется на этапе компиляции, потому что сам по себе инстанс RTTI<T> не содержит виртуальных методов.

Поэтому, возвращаемый уникальный ид вычисляется на этапе компиляции. Дальше уже вызывающая сторона может сравнивать получаемый ид - это то что нужно, или что-то другое.

Получаем идентификацию для полиморфов, без издержек в рантайме.

А вообще, есть целые паттерны, как изготовить быстрый RTTI для полиморфов, с "автоматическим уникальным ид", и тп.

[waleri]

То, что вы делаете это то же RTTI, только с вашими структурами - в принципе никакой разницы.
RTTI вкллючает скрытый виртуальный метод, который возрващает структуру, в которой тоже нет виртуальных методов. Ключевое то, что в объекте нужно делать виртуальный метод, а не то, как сгенерить уникальное ID для каждого типа. Тут даже и template ненужен static type_info сойдет не хуже.

Время в рантайме кушает не определение типа (там то же самое что и у вас) а динамический каст - это может оказаться довольно медленным, особено если есть множественное или виртуальное наследование.

[_Bers]

Сообщение от waleri

То, что вы делаете это то же RTTI, только с вашими структурами - в принципе никакой разницы.
RTTI вкллючает скрытый виртуальный метод, который возрващает структуру, в которой тоже нет виртуальных методов. Ключевое то, что в объекте нужно делать виртуальный метод, а не то, как сгенерить уникальное ID для каждого типа. Тут даже и template ненужен static type_info сойдет не хуже.

Время в рантайме кушает не определение типа (там то же самое что и у вас) а динамический каст - это может оказаться довольно медленным, особено если есть множественное или виртуальное наследование.

Опять двадцать пять: унаследовался от полиморфа? typeid задействуют RTTI.

А если сделать typeid(ptr->GetTypeInfo() )

Где GetTypeInfo возвращает const type_info& не_полиморфного типа, а значит, вычисляемого времени компиляции, то никаких потерь в рантайме уже не будет. Не будет никаких динамических кастов.

Смысл в том, что бы для полиморфа не использовать встроенное RTTI

[waleri]

Сообщение от _Bers

Где GetTypeInfo возвращает const type_info& не_полиморфного типа, а значит, вычисляемого времени компиляции, то никаких потерь в рантайме уже не будет.

Стандартный RTTI тоже возвращает структуру неполиморфного типа, вычисляемой во время компиляции - так где отличия? А если нет разницы, тогда зачем это делать? Таким образом вы будете вызывать виртуальную функцию сами, вот и все, тогда как в случае RTTI о подробностях будет заботиться компилятор. Кроме того, вы же сами говорили, что если у класса нет виртуальной таблицы typeid будет работать невиртуально а type_info все равно не полиморфна.

Единственный смысл делать свое RTTI это ограничить функционал и соотвественно размер программы но смысла в этом нет. Чтоб сделать хоть чтото смысленное надо будет заставлять программиста не ошибаться, ведь в type_info надо будет ставить ссылку на родителя (и не дай бог родителей) а без динамического каста вообще все теряет смысл, кроме одного частного случая когда у всех классов один и только один родитель, чего за пределами академических задач редко увидиш.

[rmv240899]

ТС, так не передавайте в функцию void *, сделайте её шаблонной. Например так.

[waleri]

А не проще будет сделать несколько функций с одним именем и с разным типом аргументов для разных структур?

[rmv240899]

ТС уже говорил, что вариант с перегрузкой ему не подходит.

[_Bers]

Сообщение от waleri

Стандартный RTTI тоже возвращает структуру неполиморфного типа, вычисляемой во время компиляции - так где отличия?

Смысл не в том, что именно возвращает typeid, а в том, что ты скармливаешь ей.

typeid(ptr->GetTypeInfo() );

Что именно ты пихаешь в качестве аргумента typeid?
Если ты пихаешь туда полиморфный объект, то прими мои поздравления: динамик_каст и потери производительности - твои лучшие друзья.