Я знаю их не так много (точнее совсем почти не знаю), но в Java например это сделано отдельным пакетом (java.lang.reflect). В VCL это сделано так же отдельным классом, описывающим тип. Возможно, что и тут имеет смысл сделать нечто, расширяющее RTTI.   

например что/как и что желательно получить в итоге?

Добавлено через 3 минуты и 24 секунды
xvr, говорю же: мне, конкретно для моей задачи необходимы два момента:
1. генерация сериализаторов/десериализаторов.
2. reflection с возможностью указать куда и как рефлектиться. т.е. - сериализатор, БД, другой объект этого же типа.

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

Погляди в Java, там есть класс Class, описывающий классы, экземпляр которого можно получить например так:

а из него можно получить всю информацию, например методы, поля, суперклассы и т. д...

спасибо. гляну.

•  Описатель структуры класса: все поля, методы. Включая их тип, сигнатуру параметров (для методов) и пр. Вот только не инстанциированные шаблоны так не получишь (и видимо вообще не получишь)
•  Метод для создания экземпляра класса
•  Метод для получения этого самого расширенного RTTI (в виде класса) по имени типа (в виде строки или идентификатора) или из существующего экземпляра объекта

осталось понять как это должно выглядеть в коде 


метод, или способ? тот же вопрос: как это должно выглядеть в коде?


т.е. _этот_расширенный_RTTI_ - это должен быть некий тип/класс?


и снова тот же вопрос: как это должно выглядеть в коде?

Например так:


К сожалению в С++ нету базового класса похожего на Object в Java, поэтому единственный на мой взгляд способ вернуть новый экземпляр класса, созданный через reflection - вернуть void*.

тут Class это кто? какая-то встроенная сущность?
а MyClass кто?
и в общем, что выполняется в этой строке?

итак. с чем разобрался:
1. для каждой единицы трансляции формируется Abstract syntax tree.
2. реальный компилятор(cc1plus) обрабатывает только по одному файлу за раз. при передаче g++ нескольких файлов, он поочередно выполняет cc1plus для каждого файла. а значит плагин будет запускаться столько же раз, сколько файлов.
3. есть возможность навесить свой обработчик на: 1) окончание разбора единицы трансляции, 2) глобальную обработку прагм, 3) глобальную обработку атрибутов.
4. плагин может добавлять/удалять в базу стандартных прагм и атрибутов свои прагмы и атрибуты.
5. есть возможность навесить обработчик на какую-то конкретную прагму или атрибут. т.е. сначала регаем имя, потом вешаем свой обработчик на реганное имя.
6. нет возможности навесить обработчик на разбор деклараций :( хотя в инете есть патч для этого.
7. нет возможности влиять на синтаксис языка.
8. AST можно генерить/изменять/удалять. т.е. при изменении AST можно с кодом сделать все что угодно.

далее...

Это сообщение отредактировал(а) boostcoder - 26.7.2011, 09:47

Пора уходить на более другой язык. 

условно :
Class - type_info
MyClass - struct MyClass
MyClass.class - typeid(MyClass)

но применительно не для всех типов, а только для полиморфных.. что позволяет после создания объекта имея ссылку на класс динамически кастовать его к нужному интерфейсу.. 

EnergoHokum, нет нужды 

mes, а можете показать то же самое ,но в виде примера на с++? ;) т.е. каким вы видите использование, и какие дополнительные возможности должен предоставлять этот самый расширенный type_info?

Добавлено через 1 минуту
и да, type_info и typeid() никогда не использовал  

это я к тому, что не очень представляю для чего они нужны, и как их использовать.

вот на скорую руку : http://liveworkspace.org/code/1e9029d8cabe...e9920a195e3336a

не понимаю... 

Добавлено через 6 минут и 52 секунды
mes, т.е. смысл в том, чтоб объект мог создать объект своего же типа? а как это можно использовать?
еще не понял что Вы хотели продемонстрировать с помощью dynamic_cast?