Reflection for C++ - C/C++

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, yxiie:

SD>имхо вы хотите того чего не нужно никому и никогда.
SD>зачем тут нужна рефлексия?

эээ... не понял

SD>чтобы скрипт вызвал нужный метод достаточно зарегистрировать в виртуальной машине как его вызывать.
SD>Самый простой способ — автоматическая регистрация : те
SD>*при компиляции с++ создаются заглушки, которые преобразовывают аргументы пришедшие из скрипта в нормальный вызов с++ метода
SD>*при компиляции с++ создается код который регистрирует заглушки в скрипте при старте vm

может быть, а чтобы скрипт создал экземпляр native C++ класса?

SD>после этого юзер может скриптить сколько угодно.
SD>Главная проблема — интерфейсы менять уже будет нельзя или скрипты придется выкинуть и писать наново.

SD>wbr

SD>зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор

честно говоря я абсолютно не понял, что вы хотели сказать

это замечание? возражение? уточнение?

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, SleepyDrago, Вы писали:

SD>>Здравствуйте, yxiie:

SD>>имхо вы хотите того чего не нужно никому и никогда.
SD>>зачем тут нужна рефлексия?

Y>эээ... не понял

SD>>чтобы скрипт вызвал нужный метод достаточно зарегистрировать в виртуальной машине как его вызывать.
SD>>Самый простой способ — автоматическая регистрация : те
SD>>*при компиляции с++ создаются заглушки, которые преобразовывают аргументы пришедшие из скрипта в нормальный вызов с++ метода
SD>>*при компиляции с++ создается код который регистрирует заглушки в скрипте при старте vm

Y>может быть, а чтобы скрипт создал экземпляр native C++ класса?

Запросто — зарегать фабрику этого класса

+ зарегать сам класс //он же статически скомпилен уже

SD>>зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор
Y>честно говоря я абсолютно не понял, что вы хотели сказать

Y>это замечание? возражение? уточнение?

вопрос к афтору — "зачем и для чего нужна такая система".
если я правильно понял то и мне такая нужна — только руки никак не доходили.

wbr

Здравствуйте, SleepyDrago, Вы писали:

SD>Запросто — зарегать фабрику этого класса

SD>+ зарегать сам класс //он же статически скомпилен уже

ну дак по большому счету script-binding это и есть большая умная фабрика

му уже это обсуждали где-то в теме, нет желания по второму кругу воду в ступе.

SD>>>зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор
Y>>честно говоря я абсолютно не понял, что вы хотели сказать

Y>>это замечание? возражение? уточнение?

SD>вопрос к афтору — "зачем и для чего нужна такая система".
SD>если я правильно понял то и мне такая нужна — только руки никак не доходили.

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

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, yxiie, Вы писали:

Y>ну дак по большому счету script-binding это и есть большая умная фабрика

Y>му уже это обсуждали где-то в теме, нет желания по второму кругу воду в ступе.

Дык ИМХО рефлексия тут не причем. Есть код назовем его "А" и нужно получить по нему код
врапперов назовем его "Б". причем процесс получения это часть процесса сборки.
Тут уже много раз писали переписали на эту тему (вон недавно Кодт хотел через DIA для сериализации)
ну и воз и ныне там.
Если у Вас есть идея как это сделать надежно — поделитесь.
Если нет и только спрашиваете — тогда ответ никак. Своими хаками через парсеры кода, через DIA или даже ручками — одинаково ненадежно и неудобно ИМХО.

Личный опыт — каждое изменение в интерфейсе с++ -> скрипт будет давать вам тонны нерабочих скриптов
при том что отладчика скриптов как правило нет или он с трудом понимает ваши с++ расширения.
Отсюда глубокое имхо менять эти интерфейсы так редко и так внимательно что РУКАМИ это САМЫЙ надежный способ. Пример кода заглушки

int create_group(lua_State*L){
    DECL(ScriptLib);
    const char* grname=0;
    ARGN(2);
    SELF(ScriptLib);
    STR(grname, 2);
    INVOKE0(CreateGroup(grname), e_crg);
    ERR;
}

Так что проблемы не в рефлексии

напишите если что путное выйдет.

wbr

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, yxiie, Вы писали:

Y>>ну дак по большому счету script-binding это и есть большая умная фабрика

Y>>му уже это обсуждали где-то в теме, нет желания по второму кругу воду в ступе.

SD>Дык ИМХО рефлексия тут не причем. Есть код назовем его "А" и нужно получить по нему код
SD>врапперов назовем его "Б". причем процесс получения это часть процесса сборки.
SD>Тут уже много раз писали переписали на эту тему (вон недавно Кодт хотел через DIA для сериализации)
SD>ну и воз и ныне там.
SD>Если у Вас есть идея как это сделать надежно — поделитесь.

что сделать???

вы что-то надумали себе и хотите, чтобы я о чем-то поделился. внимательно перечитайте всю эту тему. если что-то *конкретное* не понятно — спрашивайте, а то тут какие-то врапперы пошли, какой-то процесс получения...

SD>Если нет и только спрашиваете — тогда ответ никак. Своими хаками через парсеры кода, через DIA или даже ручками — одинаково ненадежно и неудобно ИМХО.

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

SD>Личный опыт — каждое изменение в интерфейсе с++ -> скрипт будет давать вам тонны нерабочих скриптов
SD>при том что отладчика скриптов как правило нет или он с трудом понимает ваши с++ расширения.
SD>Отсюда глубокое имхо менять эти интерфейсы так редко и так внимательно что РУКАМИ это САМЫЙ надежный способ. Пример кода заглушки
SD>

SD>int create_group(lua_State*L){
SD>    DECL(ScriptLib);
SD>    const char* grname=0;
SD>    ARGN(2);
SD>    SELF(ScriptLib);
SD>    STR(grname, 2);
SD>    INVOKE0(CreateGroup(grname), e_crg);
SD>    ERR;
SD>} 
SD>

SD>Так что проблемы не в рефлексии

SD>напишите если что путное выйдет.

SD>wbr

вообще полный мрак, я плакалъ

мне тут еще Lua не хватало.

опять же, давайте общаться так, чтобы я понимал, что вы хотите от меня услышать...

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, yxiie, Вы писали:

Y>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке. а варианты с DDL и специальными парсерами мне очень не нравятся — все должно быть на С++

Доктор ! где здесь рефлексия ?
*Есть статически скомпиленная иерархия классов С++
*Есть динамический скрипт который цепляется к ней и расширяет эту иерархию.

Я вижу 2 пути :
script vm + зарегистрированные врапперы.
script vm + динамическая объектная модель на скрипте //типичный пример Unreal Script

в первом случае осталось напарить эти самые врапперы из объявлений классов
во втором — предстоит создать хороший отладчик скриптов.

wbr
зы поменьше эмоций.
Мне самому нужно нечто подобное так что "удачи!".

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, yxiie, Вы писали:

Y>>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке. а варианты с DDL и специальными парсерами мне очень не нравятся — все должно быть на С++

А>Доктор ! где здесь рефлексия ?
А>*Есть статически скомпиленная иерархия классов С++
А>*Есть динамический скрипт который цепляется к ней и расширяет эту иерархию.

а динамическая именованая иерархия, которая дублирует статическую иерархию на С++ это что?
приведи мне твое определение рефлексии...

А>wbr
А>зы поменьше эмоций.

если содержание сообщений не будет вилять туда-сюда, от DIA до LUA, я не буду огорчаться по поводу невозможности аргументированно ответить

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, yxiie, Вы писали:

SD>>Если нет и только спрашиваете — тогда ответ никак. Своими хаками через парсеры кода, через DIA или даже ручками — одинаково ненадежно и неудобно ИМХО.

Y>какие парсеры, какой DIA — у меня первым пунктом стоит портабельность, а парсеры — это не мой стиль.
Y>я вроде уже еао197 объяснил — он все понял, что я хочу делать. Будьте добры, перечитайте и вы тему, чтобы задавать вопросы которые я пойму и смогу ответить.

Что бы прояснить: я понял (как мне кажется), что хочет yxiie. Но, во-первых, я не думаю, что так нужно делать (я согласен с предложениями SleepyDrago). И, во-вторых, я не уверен, что из этого что-либо хорошее получится. Но, т.к. это только мое имхо, то я решил свернуть тему.

Все равно желаю, тебе, yxiie, удачи! Дело это сложное, но интересное.

Если что-то получится и можно будет озвучить результаты -- поделись впечатлениями, ладно?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, <Аноним>, Вы писали:

А>>Здравствуйте, yxiie, Вы писали:

извиняюсь — глюкнул браузер те аноним это я

Y>>>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке. а варианты с DDL и специальными парсерами мне очень не нравятся — все должно быть на С++

А>>Доктор ! где здесь рефлексия ?
А>>*Есть статически скомпиленная иерархия классов С++
А>>*Есть динамический скрипт который цепляется к ней и расширяет эту иерархию.

Y>а динамическая именованая иерархия, которая дублирует статическую иерархию на С++ это что?
Y>приведи мне твое определение рефлексии...

Вместо этого я предлагаю Вам подумать над тем:
*** в какой среде будет исполняться

Y>а динамическая именованая иерархия, которая дублирует статическую иерархию на С++

?

ответ на этот вопрос должен сильно прояснить природу исходного вопроса

Y>>>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке.

имхо все остальные вопросы по рефлексии и генерации кода _после_ ответа на ***
должны просто отпасть

wbr

Здравствуйте, yxiie, Вы писали:

Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания.
Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:

Y>1. Портабельная
Y>2. Быстрая
Y>3. Удобная
Y>4. Бесплатная

Y>Эта вещь мне в принципе нравится, но хотелось бы индустриально опробованное и поддерживаемое решение.

Yxiie, если ты планируешь создать скриптовый язык для программирования игр, то может быть имеет смысл посмотреть сначала в сторону языка Pike. Он очень похож на C++, но интерпритируется. Изначально он как раз и создавался для разработки игр. А его разработчики уверяют, что у него очень высокая скорость работы для своего класса языков.

Если ты занимаешься разработкой своей задачи не для собственного интереса, то может имеет смысл глянуть на уже готовые решения в области скриптовых языков? Ведь создать свой скриптовый язык, более мощный, чем тот же Pike, ох как не просто. Хотя, если ты это делаешь в качестве хобби, то это совсем другое дело

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Хотелось бы вернуть обсуждение в более конструктивное русло.
Итак, у нас есть структуры, описывающие методы и поля. Чтобы дать возможность обратиться к этим полям и методам, мы должны сделать некий map, один на каждый класс, в котором мы будем регистрировать метаданные, после чего обращаться к ним через map. Но вот меня интересует следующий вопрос: ведь метаданные статичны, однако мы будем создавать их как минимум один раз для каждого класса. Хотелось бы получить статичный метод вызова, который бы решал этот вопрос более эффективынм, быстрым и надежным путем.

Здравствуйте, sch, Вы писали:

sch>Хотелось бы вернуть обсуждение в более конструктивное русло.

Ok. Давайте пофантазируем о reflection в С++ вообще, безотносительно к прикладной задаче yxiie.

sch>Итак, у нас есть структуры, описывающие методы и поля. Чтобы дать возможность обратиться к этим полям и методам, мы должны сделать некий map, один на каждый класс, в котором мы будем регистрировать метаданные, после чего обращаться к ним через map. Но вот меня интересует следующий вопрос: ведь метаданные статичны, однако мы будем создавать их как минимум один раз для каждого класса. Хотелось бы получить статичный метод вызова, который бы решал этот вопрос более эффективынм, быстрым и надежным путем.

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

Очень хорошо по этому поводу высказался Константин Книжник. Лично я к этом могу добавить только следующее: т.к. reflection не поддерживается на уровне языка (как в Java, например) то остается всего два пути для получения портабельного решения. Либо делать ручное описание классов, их атрибутов и методов с помощью макросов или шаблонов. Либо использовать внешние инструменты, которые генерят С++ код с метаданными по каким-то описаниям. Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.

В варианте с внешними инструментами возможны два подхода:

1. Описание схемы данных делается на специальном Data Definition Language, а не на C++. Затем это описание пропускается через специализированный транслятор, который и строит код с метаданными. Простой вариант с точки зрения реализации такого транслятора, особенно, если синтаксис DDL прост. Может быть слишком трудоемким в использовании, если одни и те же данные нужно будет описывать и на C++ и на DDL. Возможный выход -- генерация по DDL описанию не только кода с метаданными, но и самих описаний C++ типов.

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

2. Описание схемы данных поднимается из обычного C++ описания. Проблема состоит в создании парсера C++, который бы мог это делать. Она может быть решена, например, использованием таких средств как gcc-xml, CInt. Так же adontz нашел какую-то возможность извлекать эту информацию из C++ кода для Visual Studio (Проект сериализации — 2 [просьба высказаться]), но его способ выглядит не портабельным.

Я также рассматривал еще вариант использования инструментов типа doxygen и ccdoc: в комментариях к классам, методам, атрибутам выставляешь специальные теги, которые игнорируются обычным doxygen (ccdoc), но извлекаются их модифицированными версиями. Затем строится код с метаданными. Вот, например, как это могло выглядеть:

/*!
    \brief Информация о пользователе.
    \reflected
    
    Хранит login, имя, описание пользователя, а также ...
*/
class    user_info_t
    {
    private :
        /*!
            \brief Логин пользователя.
            \reflected
        */
        std::string    m_login;
        ...
    public :
        /*!
            \brief Конструктор по-умолчанию.
            \reflected
        */
        user_info_t();
        /*!
            \brief Устанавливает имя пользователя и пароль.
            \reflected
        */
        user_info_t(
            const std::string & login,
            const std::string & password );
        ...
    };

Мне больше симпатичны способы с отдельным DDL или последний способ с doxygen (ccdoc) /фактически, это очень похоже на DDL, который растворен в C++/. Такие способы позволяют делать дополнительные описания, которые нельзя сделать в C++, но которые могут быть полезны, например, при сериализации.

Вообще, имхо, механизм reflection в Java крут и полезен благодоря одной важной фишке: возможности вызова метода не зная заранее его сигнатуры и передавая все параметры ему в виде Object[]. В C++ я не знаю портабельного способа для выполнения этого. Отсюда, лично для меня, следуют следующие выводы:
— если в C++ механизм reflection нужен для инстанцирования объектов по строковому имени их класса, то для этого подходят фабрики;
— если в C++ механизм reflection нужен для сериализации, то готовых решений для сериализации уже как собак не резаных развелось. Более того, для сериализации может быть черезвычайно важна информация, которую нельзя представить в синтаксисе C++. Например, является ли атрибут необязательным (т.е. должен ли он сериализоваться, если содержит значение по-умолчанию). А так же в сериализации нужно решать вопросы версионности сериализованных образов, для которых так же может потребоваться дополнительная информация;
— если в C++ механизм reflection нужен для вызова произвольных методов с произвольными сигнатурами, то, имхо, портабельно это сделать невозможно. Все равно придется органичиваться какими-то методами с известными сигнатурами (тогда можно использовать интерфейсы и фабрики) или придется писать обертки для того, чтобы сделать нормальный вызов, выбрав все параметры из какого-нибудь std::vector< script_expression_t * >. Но и эти задачи уже были неоднократно решены применительно к скриптовым языкам.

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, eao197, Вы писали:

E>Очень хорошо по этому поводу высказался Константин Книжник. Лично я к этом могу добавить только следующее: т.к. reflection не поддерживается на уровне языка (как в Java, например) то остается всего два пути для получения портабельного решения. Либо делать ручное описание классов, их атрибутов и методов с помощью макросов или шаблонов. Либо использовать внешние инструменты, которые генерят С++ код с метаданными по каким-то описаниям. Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.

E>В варианте с внешними инструментами возможны два подхода:

E>1. Описание схемы данных делается на специальном Data Definition Language, а не на C++. Затем это описание пропускается через специализированный транслятор, который и строит код с метаданными. Простой вариант с точки зрения реализации такого транслятора, особенно, если синтаксис DDL прост. Может быть слишком трудоемким в использовании, если одни и те же данные нужно будет описывать и на C++ и на DDL. Возможный выход -- генерация по DDL описанию не только кода с метаданными, но и самих описаний C++ типов.

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

интересно, чем этот вариант отличается от ручного задания формата класса (регистрация полей и методов) в плане

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

?

...

E>Вообще, имхо, механизм reflection в Java крут и полезен благодоря одной важной фишке: возможности вызова метода не зная заранее его сигнатуры и передавая все параметры ему в виде Object[].

вот это я тоже собираюсь сделать (вернее мне придется) — передавать параметры из скрипта в виде неких Object*

E>В C++ я не знаю портабельного способа для выполнения этого. Отсюда, лично для меня, следуют следующие выводы:
E>- если в C++ механизм reflection нужен для инстанцирования объектов по строковому имени их класса, то для этого подходят фабрики;
E>- если в C++ механизм reflection нужен для сериализации, то готовых решений для сериализации уже как собак не резаных развелось. Более того, для сериализации может быть черезвычайно важна информация, которую нельзя представить в синтаксисе C++. Например, является ли атрибут необязательным (т.е. должен ли он сериализоваться, если содержит значение по-умолчанию). А так же в сериализации нужно решать вопросы версионности сериализованных образов, для которых так же может потребоваться дополнительная информация;
E>- если в C++ механизм reflection нужен для вызова произвольных методов с произвольными сигнатурами, то, имхо, портабельно это сделать невозможно. Все равно придется органичиваться какими-то методами с известными сигнатурами (тогда можно использовать интерфейсы и фабрики) или придется писать обертки для того, чтобы сделать нормальный вызов, выбрав все параметры из какого-нибудь std::vector< script_expression_t * >. Но и эти задачи уже были неоднократно решены применительно к скриптовым языкам.

суну сюда еще одни 5 копеек — reflection удобно использовать для отладки не выходя из приложения (особено, если оно полноэкранное). например навел мышью на игровой объект — а оно тебе в hint-е показывает свойства его класса. в дебаггере такого просто не сделаешь — найти объект в определенном месте не экране.
да и нельзя будет это проследить в динамике.

E>Поэтому для меня, reflection в C++ -- это баловство, попытка перенести в язык концепцию, взятую из принципиально другого языка. По крайней мере сейчас, пока в C++ нет стандартной поддержки reflection.

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

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, eao197, Вы писали:

E>Yxiie, если ты планируешь создать скриптовый язык для программирования игр, то может быть имеет смысл посмотреть сначала в сторону языка Pike.

спасибо, посмотрю.

E>Он очень похож на C++, но интерпритируется. Изначально он как раз и создавался для разработки игр.

нет, скрипт язык будет однозначно JavaScript или клон его. как я уже писал, практика показывает, что он достаточно простой для того, чтобы даже дизайнеры могли его использовать. кроме того человеку можно сказать просто: купи книгу по JavaScript а не объяснять особенности доморощенного синтаксиса или писать доку по своему языку (бррр...)

E>А его разработчики уверяют, что у него очень высокая скорость работы для своего класса языков.

ну скорость в принципе не фатальна, т.к. на скрипт-языке не будут решаться time-critical задачи.

E>Если ты занимаешься разработкой своей задачи не для собственного интереса, то может имеет смысл глянуть на уже готовые решения в области скриптовых языков?

смотрел

E> Ведь создать свой скриптовый язык, более мощный, чем тот же Pike, ох как не просто.

еще не смотрел Pike, но скажу что реализовать JavaScript не так уж и трудно. клон последнего я сделал, когда только начинал изучать С++ (собственно в процессе написания подобного интерпретатора я и изучал С++

)

E>Хотя, если ты это делаешь в качестве хобби, то это совсем другое дело

ну, я стараюсь совмещать приятное с полезным

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, eao197, Вы писали:

E>Что бы прояснить: я понял (как мне кажется), что хочет yxiie. Но, во-первых, я не думаю, что так нужно делать (я согласен с предложениями SleepyDrago). И, во-вторых, я не уверен, что из этого что-либо хорошее получится. Но, т.к. это только мое имхо, то я решил свернуть тему.

E>Все равно желаю, тебе, yxiie, удачи! Дело это сложное, но интересное.

я не говорил, что будет просто

кстати есть реальные примеры того, что я хочу:
игровой движок Nebula интегрирован с Tcl/Tk так как я хочу интегрировать с JavaScript...

E>Если что-то получится и можно будет озвучить результаты -- поделись впечатлениями, ладно?

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

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, yxiie, Вы писали:

<...>

Y>нет, скрипт язык будет однозначно JavaScript или клон его. как я уже писал, практика показывает, что он достаточно простой для того, чтобы даже дизайнеры могли его использовать. кроме того человеку можно сказать просто: купи книгу по JavaScript а не объяснять особенности доморощенного синтаксиса или писать доку по своему языку (бррр...)

А вот это (DMDScript) ты рассматривал?

E>>А его разработчики уверяют, что у него очень высокая скорость работы для своего класса языков.

Y>ну скорость в принципе не фатальна, т.к. на скрипт-языке не будут решаться time-critical задачи.

Думаю, что это не надолго.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

Y>интересно, чем этот вариант отличается от ручного задания формата класса (регистрация полей и методов) в плане
Y>

Y>Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.

Y>?

Видимо, eao197 имел ввиду, что при каждом изменении сигнатуры метода придется переписывать и определение. Однако я такую проблему решил следующим образом:

template<class Variant>
class ReflectedMethod {
public:
virtual ~ReflectedMethod()=0 {}
virtual Variant Call(const std::vector<Variant> &args)=0;
};

template<class Variant>
class ReflectedClass {
private:
typedef std::map<std::string,ReflectedMethod<Variant> *> mtable_t;
mtable_t mtable;

public:
ReflectedClass() {
}

~ReflectedClass() {
 for(mtable_t::iterator i=mtable.begin(); i!=mtable.end(); i++) delete i->second;
}

void RegisterMethod(const char *name,ReflectedMethod<Variant> *method) {
 mtable[name]=method;
}

Variant Call(const char *method,const std::vector<Variant> &args) {
 mtable_t::iterator i=mtable.find(method);
 if(i != mtable.end()) return i->second->Call(args);
 assert(0);
 return 0;
}
};

template<class Result,class Object,class Param1,class Variant>
class Method_1: public ReflectedMethod<Variant> {
private:
Object *object_ptr;
Result (Object::*method_ptr)(Param1 p1);

public:
Method_1(Object *object,Result (Object::*method)(Param1 p1)):
object_ptr(object),method_ptr(method) {
}

Variant Call(const std::vector<Variant> &args) {
 return (Variant)(object_ptr->*method_ptr)((Param1) args[0]);
}
};

template<class Result,class Object,class Param1,class Param2,class Variant>
class Method_2: public ReflectedMethod<Variant> {
private:
Object *object_ptr;
Result (Object::*method_ptr)(Param1 p1,Param2 p2);

public:
Method_2(Object *object,Result (Object::*method)(Param1 p1,Param2 p2)):
object_ptr(object),method_ptr(method) {
}

Variant Call(const std::vector<Variant> &args) {
 return (Variant)(object_ptr->*method_ptr)((Param1) args[0],(Param2) args[1]);
}
};
// etc.

template<class Result,class Object,class Param1,class Variant>
inline Method_1<Result,Object,Param1,Variant> *declaration(Object *object_ptr,Result (Object::*method_ptr)(Param1 p1),Variant dummy) {
return new Method_1<Result,Object,Param1,Variant>(object_ptr,method_ptr);
}

template<class Result,class Object,class Param1,class Param2,class Variant>
inline Method_2<Result,Object,Param1,Param2,Variant> *declaration(Object *object_ptr,Result (Object::*method_ptr)(Param1 p1,Param2 p2),Variant dummy) {
return new Method_2<Result,Object,Param1,Param2,Variant>(object_ptr,method_ptr);
}
// etc.

Соответственно, описание методов выглядит так:

// естественно в качестве варианта можно и нужно использовать variant;)
class A: public ReflectedClass<int> {
public:
int fn(int p1) {
 printf("A::fn(%d)\n",p1);
 return 1;
}

int fnx(int p1,int p2) {
 printf("A::fnx(%d,%d)\n",p1,p2);
 return 1;
}

A() {
 RegisterMethod("fn",declaration(this,fn,int()));
 RegisterMethod("fnx",declaration(this,fnx,int()));
}
};

Здравствуйте, sch, Вы писали:

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

Y>>интересно, чем этот вариант отличается от ручного задания формата класса (регистрация полей и методов) в плане
Y>>

Y>>Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.

Y>>?

sch>Видимо, eao197 имел ввиду, что при каждом изменении сигнатуры метода придется переписывать и определение. Однако я такую проблему решил следующим образом:
...

да нет, тут наверное что-то другое, т.к. такое решение есть и у Batiskaf-a а мы это уже давно обсудили.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, eao197, Вы писали:

E>>В варианте с внешними инструментами возможны два подхода:

E>>1. Описание схемы данных делается на специальном Data Definition Language, а не на C++. Затем это описание пропускается через специализированный транслятор, который и строит код с метаданными. Простой вариант с точки зрения реализации такого транслятора, особенно, если синтаксис DDL прост. Может быть слишком трудоемким в использовании, если одни и те же данные нужно будет описывать и на C++ и на DDL. Возможный выход -- генерация по DDL описанию не только кода с метаданными, но и самих описаний C++ типов.

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

Y>интересно, чем этот вариант отличается от ручного задания формата класса (регистрация полей и методов) в плане
Y>

Y>Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.

Y>?

Если ты о варианте с ручным описанием вообще, то я действительно считаю, что нет большой разницы между дублированием описания в C++ коде при помощи макросов или шаблонов, или в DDL-описании. При тривиальной реализации С++ макросы (шаблоны) даже предпочтительнее, т.к. компилятор может выдавать ошибки, если тип атрибута изменился в C++ классе, но не в описании для reflection. Однако, вариант с DDL оставляет возможность автоматической генерации C++ кода, включая описания C++ классов, только по одному DDL описанию. Так, например, из CORBA IDL получается сразу куча уже готовых классов. Так же и в gSOAP.

Я же для себя выбрал свой DDL-вариант, учитывая последний аргумент и еще один важный фактор: DDL можно расширять независимо от языка C++. Например, сначала мой DDL позволял только повторить описание наследования и списка атрибутов. Затем в DDL добавилась возможность описывать атрибуты по-умолчанию (что сложно сделать C++ макросами), затем возможность описывать расширяемые типы, затем возможность описывать наследование расширением (эта такая моя фишка в сериализации). Последние две возможности в C++ было бы затруднительно реализовать. Потребовалась бы крутая и навернутая система макросов и шаблонов. И, вероятно, такое описание было бы не читабельным. А DDL позволят делать такие описания декларативными и понятными.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, yxiie, Вы писали:

Y>Здравствуйте, eao197, Вы писали:

E>>Да понимаю я это, ты мне вот что покажи:

Y>>>таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать
Y>>>параметры из скрипта и на основе их делать вызов.

E>>Как???

Y>


Y>class InvokeFromScript {
Y>public:
Y>    virtual Object* Invoke(Object* self, ScriptArgumentsClass* args);
Y>}

Y>template<    typename RType, 
Y>                    typename Param1,
Y>                    typename Param2,
Y>                    typename Obj >
Y>class InvokeFromScriptImpl2 {
Y>public:
Y>    typedef RType    (Obj::*Method)(    Param1, Param2);

Y>    InvokeFromScriptImpl2(Method mth): method(mth) {}
    
Y>    virtual Object* Invoke(Object* self, ScriptArgumentsClass* args) {
Y>        return ObjectFromType(((Obj*)self)->*method(args->GetArgument<Param1>(0), args->GetArgument<Param2>(1)));        
Y>    }    
    
Y>protected:
Y>    Method method;
Y>}

Y>...
Y>void    BindMethod(    const std_string&    name,
Y>                                RType    (Obj::*method)(    Param1, 
Y>                                                        Param2)) {
Y>...
Y>// тут сохраняем InvokeFromScript<Rtype, Param1, Param2, Obj>(method)
Y>...                                                        
                                                        

Y>

Y>конечно это все быстрый набросок, но надеюсь идея ясна.
Вечер добрый. Не думал что такими экзотическими для С++ программиста штуками (рефлексия) кто то еще заинтересуется. В свое время я думал соорудить динамическую версию метод-прокси, в дополнение к той статической версии, которая для программистов С++ гораздо более удобна. Но времени на все не хватило, успел только VariantProperty (см. Property.h file). Если есть желание и время можете добавить по аналогии с VariantProperty.

Хотя так не долго и до джавы со смолтоком дожиться, от лукавого это все

От:	yxiie	www.enkord.com
Дата:	09.03.05 18:26
Оценка:

	От:	SleepyDrago
	Дата:	09.03.05 18:43
	Оценка:

От:	yxiie	www.enkord.com
Дата:	09.03.05 18:57
Оценка:

	От:	SleepyDrago
	Дата:	09.03.05 19:52
	Оценка:

От:	yxiie	www.enkord.com
Дата:	09.03.05 20:04
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	09.03.05 21:49
Оценка:

От:	Batiskaf	http://www.mult.ru/
Дата:	10.03.05 15:39
Оценка: