По одной штуке rtti_ex_ на каждый тип


Я уже где то писал вверху - таблиц должно быть 2 штуки (точнее 2 набора таблиц) - 1 набор с RTTIEx (rtti_ex_) на каждый тип (извлекаются по уникальному имени, приблизительно таким же, как таблица для обычного RTTI). А вторая таблица - общая для всей программы. В нее складываются имена типов классов и адреса в 1ю таблицу RTTIEx.

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

Вот пример:
Вот результат 

А вот он же, но с демангленными именами:

понял!


буду усваивать.

Строка 81 - таблица RTTI для класса A помещена в отдельную секцию (строка 82,86) с уникальным именем с пометкой для линкера (строка 83,88) оставить только 1 экземпляр этой секции. Причем отдельно размещены имя класса и собственно таблица typeinfo

В строке 93 в специальной секции помещается таблица для обработчика эксепшенов. Линкер соберет все такие секции со всей программы в 1 массив (секцию)

Кстати, мне тут пришла в голову мысль - стриминг данных, базирующийся на интроспекции конечно вещь весьма универсальная, но увы не очень эффективная. Т.к. в процессе работы программы будет по сути происходить интерпретация типов данных. Гораздо более эффективным был бы стримминг, для которого был бы сгенерирован готовый код на этапе трансляции. К сожалению это нельзя сделать универсальным способом, т.к. способ записи/чтения бинарного (или текстового) потока (а так же его структура) сильно зависят от приложения. Да и сам стриминг так же не может быть целиком описан только типами данных. Так что тут напрашивается некий генератор функций/классов для стриминга (видимо по некоторым, заданным пользователем шаблонам).

У меня пока нет ясного видения как это спроектировать   

xvr, спасибо. разбираюсь  

что имеется в виду?

"отправление" данных в поток (stream) , или грубо говоря сериализация.. 

после того как разобрался с получением информации, интересна стала не только сериализация(reflection), но и нормальная introspection.

стало интересно, что для Вас reflection и introspection ? 

reflection/отражение:


introspection:

вроде как я все правильно понимаю..


да и не в этом суть. xvr меня озадачил ассемблерным кодом и всем сопутствующим...
конечно, если бы кто-то ткнул в ссылку или пример, все было бы сильно проще 

Чего нет, того нет. Но есть соображение, что структуры данных (таблиц RTTIEx) должны быть по сути сериализованной версией AST (в части описания типов). 

на идею не забил. просто сейчас по теме больше общаюсь на stackoverflow и в списке рассылке gnu-gcc. вроде как есть надежда понять всю эту магию.

в общем, ковыряниями/тыканиями/читаниями, ничего не получается. доки мало. почти нет.
пришел к решению, дважды обрабатывать единицу трансляции. первый раз - для сбора инфы, второй - для компиляции.
и того, процесс получится таким:
1. запускаем компилятор+плагин для сбора информации.
2. плагин из исходного файла и собранной информации генерит временный файл и завершает компилятор.
3. компилим временный файл как обычно.

вроде все логично...

Добавлено через 1 минуту и 28 секунд
xvr, скажите, а секция данных, может быть любого размера? есть хоть какие-то ограничения?

Отдельно взятая секция не может превосходить размера адресного пространства (т.е. 4G на 32bit приложении). Форматы файлов (elf/PE) могут налагать дополнительные ограничения. Но скорее всего гораздо быстрее сломается компилятор/линкер/да и сама программа в run-time. Но в любом случае размеры любых секций до десятков мегабайт должны восприниматься без особых проблем

вот и славно.

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

http://liveworkspace.org/code/8aae0e0cfb55...28c20b3ceadf96f

начиная с 86ой строки, я пытался сэмитировать поведение.
возникло два вопроса:
1. член offset, структуры rtti_ex_, каково должно быть его значение для типов самого верхнего уровня? т.е. тех, что не являются чьими-то членами.
2. по идее, rtti_ex_, должен содержать массив типов member_type_ ? или же, rtti_ex_ должны ссылаться на другие rtti_ex_, и тип member_type_ вообще лишний?

Добавлено @ 17:55
еще непонятно как быть при декларации данных-членов, и декларации типов-членов, как например "name2::name3"

Добавлено через 13 минут и 2 секунды
по идее, в "enum type_" нужно добавить член decl_, который будет указывать на то, что элемент rtti_ex_ описывает декларацию структуры(или что еще попадает под декларации? typedef?).

Это сообщение отредактировал(а) boostcoder - 1.10.2011, 17:56