Ну например -1


И rtti_ex_ и member_type_ внутренние структуры, которые собственно и должен генерить компилятор. Пользователь должен работать только с функциональным интерфейсом (class_ и member_), и не иметь доступа к внутренней реализации.

Что касается массивов member_type_ в rtti_ex_, то да, там должен быть указатель на массив member'ов (для структур/классов). И в принципе member_type_ действительно может отсутствовать, т.к. сейчас он полностью перекрывается с rtti_ex_.

В принципе member_type_ должен содержать поле offset, имя и ссылку на rtti_ex_. rtti_ex_ не должен содержать offset.


Для них ввести специальные сущности в enum class type_

rtti_ex_ должен описывать тип, а member_type_ - инстанс (переменную верхнего уровня, или поле в структуре (типе))

ага.


понял.


действительно.


ок.

xvr, скажите, а как быть с повторами элементов глобального массива rtti_ex_? получится так, что для каждой единицы трансляции будет сгенерен такой массив. ведь элементы в таких массивах будут в большинстве своем повторяться. я понимаю(вроде как) что код использующий массив типов rtti_ex_ этой единицы трансляции будет знать только об этом массиве, и никакие перекрестные ссылки не будут иметь место. но все же, насколько это логично, и правильно ли я размышляю?

Надо бороться   

Угу. Я уже приводил пример, как с этим борются в GCC - массив создается только на этапе линковки (линкером) из содержимого специальной секции. Каждый экземпляр rtti_ex_ помещается в отдельную именованную (именем замангленного типа) виртуальную секцию, и линкер на этапе линковки выкидывает дублирующиеся элементы, а все, что осталось, помещает в массив (точнее в отдельную секцию - в GCC доступ к экземплярам rtti производится по метке с именем, а не по индексу в массиве).

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

и, оказалось, что при модификации/добавлении чего-либо в AST, оно не "портиться"(о чем я переживал), и последующие алгоритмы обработки AST схватывают абсолютно все что в нем. ведь в плагин, AST передается сразу после разбора единицы трансляции. т.е. никакие алгоритмы/оптимизаторы еще не отработали.

Это сообщение отредактировал(а) boostcoder - 5.10.2011, 01:18

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


использоваться это дело будет так:

тут, для create(), мне нужно изменить строку на такую: "new type;"
если же конструктор типа требует аргументы - заменяем так: "new type(arg1, arg2, ...);"

clone. тут мне нужно определить тип на который указывает аргумент, и сформировать такую строку: "new type(*t1);"


пока все верно?

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

Угу


Так, но есть одно 'но' - как задать аргументы? reflectpp::create должен иметь фиксированную сигнатуру, т.е. аргументы придется передавать массивом чего то типа VARIANT. Передавать через ... не вариант - это потребует знать тип и количество аргументов статически в момент вызова reflectpp::create, что сводит на нет всю идею рефлексии   


Угу

xvr, я тут вот что подумал..
для создания объектов произвольного типа, в структуру rtti_ex_ нужно добавить метод(указатель на функцию?) create(). так ведь? ну и free(), за одно.

т.е. что-то типа этого:


верно мыслю?

по поводу этого не уверен.

опишу заново свое видение всего этого добра, чтоб расставить точки где надо.

1. функция create().
возможные варианты использования:

карта типов нужна для:

т.е. нужна карта типа такой:

где ключ - хеш сумма от имени, значение - указатель на объект.
и еще одна типа такой:

где ключ - указатель на объект, значение - указатель на rtti_ex_ этого типа.
по идее, нужна еще и третья карта, позволяющая создавать объекты типа class_ по имени типа.
еще один пример:


мне не нравится присутствие трех карт.
какие предложения по этому поводу?

Это сообщение отредактировал(а) boostcoder - 6.10.2011, 16:11

во первых почему создавать, во вторых зачем Вам столько карт ?   

во вторых Вы собрали в одну лукошко разные по сути и природе явления.. 


Это сообщение отредактировал(а) mes - 6.10.2011, 16:17

mes, Ваши предложения?

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


трудно сказать, потому что концепция к которой Вы стремитесь не до конца ясна..

прежде всего rtti_ex предназначена для любых типов или только для классовых ?
если для всех, то вопрос, для чего может понадобиться создание объекта неполиморфного класса по имени ?!


Это сообщение отредактировал(а) mes - 6.10.2011, 16:26

для всех.


по простому - юзер будет в терминале вводить имя.

или же так:

или так:


Это сообщение отредактировал(а) boostcoder - 6.10.2011, 16:42

ну создал юзер тип int  как void *  и что делать с ним дальше ?
если Вы о том что в яве и шарпе можно создавать интегральные типы, так только те что являются по сути объектами.. т.е. только полиморфные типы.. 
можно конечно преврать и простые типы в полиморфные посредством например интектуального указателя.. но опять напрашивается вопрос, что за модель у нас в конце тунеля ? или просто попытка набросать побольше фичей, без учета возможностей их иоспользования ?

Добавлено через 2 минуты и 39 секунд

 хотите загнать всю стат-информацию о типах в рантайм ?