Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 08:32
Оценка:
Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания.
Интересует библиотека как можно более удовлетворяющая требования в таком порядке:

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

Эта вещь мне в принципе нравится, но хотелось бы индустриально опробованное и поддерживаемое решение.
... << RSDN@Home 1.1.3 stable >>
Re: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.05 09:36
Оценка:
Здравствуйте, yxiie, Вы писали:

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

Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:

Y>1. Портабельная

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

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


Не плохо было бы еще и требования к функциональности озвучить.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 10:23
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>Не плохо было бы еще и требования к функциональности озвучить.


чем больше тем лучше
а вообще по функциональности можно что-то сравнимое с тем, что по ссылке. а что, так много возможных решений, что нужно по ф-циональности фильтровать? ну так завали меня ссылками!
... << RSDN@Home 1.1.3 stable >>
Re: Reflection for C++
От: Tonal- Россия www.promsoft.ru
Дата: 07.03.05 11:10
Оценка:
Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания.
Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:

Y>1. Портабельная

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

Это смотрел?
Reflection Package for C++
... << RSDN@Home 1.1.4 beta 4 rev. 343>>
Re[3]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.05 11:29
Оценка:
Здравствуйте, yxiie, Вы писали:

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


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


E>>Не плохо было бы еще и требования к функциональности озвучить.


Y>чем больше тем лучше

Y>а вообще по функциональности можно что-то сравнимое с тем, что по ссылке. а что, так много возможных решений, что нужно по ф-циональности фильтровать? ну так завали меня ссылками!

Боюсь, что кроме уже предложенной ссылки на работу Константина Книжника, предложить не могу.

Просто у меня уже есть код, который по специальному DDL описанию строит вспомогательный код по созданию C++ объектов по их именам. Если направление рефлекшена будет востребовано, то я задумаюсь о том, чтобы поддержать это направление у себя. Поэтому мне и интересно, что именно от рефлекшена хочется получить:
— получение списка безовых типов?
— возможность инстанцирования и уничтожения объектов по именам типов?
— получение списка атрибутов? Получения указателей на атрибуты или значения атрибутов (как тогда быть с инкапсуляцией)?
— получение указателей на методы или непосредственный вызов указателей?

Что касается решения по ссылке, то мне оно не понравилось из-за обилия ручного кодирования.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 11:30
Оценка:
Здравствуйте, Tonal-, Вы писали:

T>Это смотрел?

T>Reflection Package for C++

да. а по лучше ничего нету?
та либа от Batiskaf мне больше понравилась.
... << RSDN@Home 1.1.3 stable >>
Re[4]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 11:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Боюсь, что кроме уже предложенной ссылки на работу Константина Книжника, предложить не могу.


E>Просто у меня уже есть код, который по специальному DDL описанию строит вспомогательный код по созданию C++ объектов по их именам. Если направление рефлекшена будет востребовано, то я задумаюсь о том, чтобы поддержать это направление у себя. Поэтому мне и интересно, что именно от рефлекшена хочется получить:

E>- получение списка безовых типов?
E>- возможность инстанцирования и уничтожения объектов по именам типов?
E>- получение списка атрибутов? Получения указателей на атрибуты или значения атрибутов (как тогда быть с инкапсуляцией)?
E>- получение указателей на методы или непосредственный вызов указателей?

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

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


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

по сути единственное, что меня не устраивает в той библиотеке — необкатанность и неподдерживаемость. ну и еще то, что она Loki использует
... << RSDN@Home 1.1.3 stable >>
Re: Reflection for C++
От: FreshMeat Россия http://www.rsdn.org
Дата: 07.03.05 11:39
Оценка:
Здравствуйте, yxiie, Вы писали:

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

Небольшой список ссылок — http://gzip.rsdn.ru/forum/?mid=937642.

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

Судя по всему, тоскливо с reflection на C++. Однако, если найдешь что-то интересное, отпиши плз
Хорошо там, где мы есть! :)
Re[2]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 12:37
Оценка:
Здравствуйте, FreshMeat, Вы писали:

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


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

FM>Небольшой список ссылок — http://gzip.rsdn.ru/forum/?mid=937642.

да, видел я его когдато, и оказывается даже отметился в той теме. жаль, что там ниче толкового нету.

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

FM>Судя по всему, тоскливо с reflection на C++. Однако, если найдешь что-то интересное, отпиши плз

вот эта вещь — то что мне нужно.
http://www.boost-consulting.com/writing/oopsla04.html
только она умерла так и не родившись как я понял, или нет?
... << RSDN@Home 1.1.3 stable >>
Re: Reflection for C++
От: hth  
Дата: 07.03.05 14:12
Оценка:
Здравствуйте, yxiie, Вы писали:

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

Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:

Y>1. Портабельная

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

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


http://root.cern.ch/root/Cint.html

обеспечивает "Full RTTI" ...
даже, какой коментарий стоял напротив class method или data member.
Например, генерация HTML документации полностью реализована на RTTI,
e.g. http://root.cern.ch/root/htmldoc/TRootGuiBuilder.html

соответствует всем перечисленным условиям
Re[2]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 14:24
Оценка:
Здравствуйте, hth, Вы писали:

hth>обеспечивает "Full RTTI" ...

hth>даже, какой коментарий стоял напротив class method или data member.
hth>Например, генерация HTML документации полностью реализована на RTTI,
hth>e.g. http://root.cern.ch/root/htmldoc/TRootGuiBuilder.html

hth>соответствует всем перечисленным условиям


Cint это же интерпретатор С++, при чем здесь библиотека для рефлексии?
... << RSDN@Home 1.1.3 stable >>
Re: Reflection for C++
От: hth  
Дата: 07.03.05 14:31
Оценка:
Здравствуйте, yxiie, Вы писали:

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

Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:

Y>1. Портабельная

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

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


++
libBFD — http://sourceware.org/binutils/docs-2.15/bfd/index.html

libbfd — это библиотека, на которой написаны всe
GNU binutils: nm, objdump ... более того, на ней написаны
ld, gdb, libtool
В двух словах, она позволяет добыть всю информацию
доступную GDB: function memory entry points, demangling,
global variables etc. Доступна на linux all flavors, bsds,
solaris, sgi etc.
Re[3]: Reflection for C++
От: hth  
Дата: 07.03.05 14:37
Оценка:
Здравствуйте, yxiie, Вы писали:

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


hth>>обеспечивает "Full RTTI" ...

hth>>даже, какой коментарий стоял напротив class method или data member.
hth>>Например, генерация HTML документации полностью реализована на RTTI,
hth>>e.g. http://root.cern.ch/root/htmldoc/TRootGuiBuilder.html

hth>>соответствует всем перечисленным условиям


Y>Cint это же интерпретатор С++, при чем здесь библиотека для рефлексии?


его можно использовать и, как dictionary/(reflection information) generator .
Re[4]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 14:46
Оценка:
Здравствуйте, hth, Вы писали:

hth>его можно использовать и, как dictionary/(reflection information) generator .


можно подробнее объяснить что и как?
... << RSDN@Home 1.1.3 stable >>
Re[2]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 14:46
Оценка:
Здравствуйте, hth, Вы писали:

hth>++

hth>libBFD — http://sourceware.org/binutils/docs-2.15/bfd/index.html

hth>libbfd — это библиотека, на которой написаны всe

hth>GNU binutils: nm, objdump ... более того, на ней написаны
hth>ld, gdb, libtool
hth>В двух словах, она позволяет добыть всю информацию
hth>доступную GDB: function memory entry points, demangling,
hth>global variables etc. Доступна на linux all flavors, bsds,
hth>solaris, sgi etc.

да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец.
либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.
также запрещено использовать C++RTTI (typeid) и exceptions.
повторюсь — мне нравится либа Batiskaf-a, за исключением некоторых нюансов. есть что-то подобное?
... << RSDN@Home 1.1.3 stable >>
Re[3]: Reflection for C++
От: hth  
Дата: 07.03.05 16:07
Оценка:
Здравствуйте, yxiie, Вы писали:

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


hth>>++

hth>>libBFD — http://sourceware.org/binutils/docs-2.15/bfd/index.html

hth>>libbfd — это библиотека, на которой написаны всe

hth>>GNU binutils: nm, objdump ... более того, на ней написаны
hth>>ld, gdb, libtool
hth>>В двух словах, она позволяет добыть всю информацию
hth>>доступную GDB: function memory entry points, demangling,
hth>>global variables etc. Доступна на linux all flavors, bsds,
hth>>solaris, sgi etc.

Y>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец.


oops ... GCC, и не только! ELF format он и в африке ELF format.
btw,libbfd работает и с другими форматами ...

Y>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.

Y>также запрещено использовать C++RTTI (typeid) и exceptions.
Y>повторюсь — мне нравится либа Batiskaf-a, за исключением некоторых нюансов. есть что-то подобное?

ну, тогда только CINT (rootcint) —
platform-compiler незавсимое решение
Re[3]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.05 16:27
Оценка:
Здравствуйте, yxiie, Вы писали:

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


hth>>++

hth>>libBFD — http://sourceware.org/binutils/docs-2.15/bfd/index.html

<...>

Y>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец.

Y>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.

Боюсь, что если без парсеров и DDL, то объем ручного программирования в конце-концов приведет к невозможности использования такого решения. Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Reflection for C++
От: hth  
Дата: 07.03.05 16:31
Оценка:
Здравствуйте, yxiie, Вы писали:

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


hth>>его можно использовать и, как dictionary/(reflection information) generator .


Y>можно подробнее объяснить что и как?


http://root.cern.ch/root/Cint.phtml?makecint
http://root.cern.ch/root/Cint.phtml?extlib
http://root.cern.ch/root/Cint.phtml?extlib


rootcint TetrisDict.cxx -c Tetris.h

Выходные файлы TetrisDict.cxx, TetrisDict.h —
содержaт reflection information generated from Tetris.h
Re[4]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 16:37
Оценка:
Здравствуйте, eao197, Вы писали:

Y>>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец.

Y>>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.

E>Боюсь, что если без парсеров и DDL, то объем ручного программирования в конце-концов приведет к невозможности использования такого решения.


ну можно на макросах...

E>Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?


все равно придется как-то описвать структуру, так пусть лучше это будет несколько макросов на месте, чем еще какие-то левые файлы или тулзы, которые нужно вызывать перед компиляцией.
... << RSDN@Home 1.1.3 stable >>
Re[5]: Reflection for C++
От: hth  
Дата: 07.03.05 16:57
Оценка:
Здравствуйте, yxiie, Вы писали:

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


Y>>>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец.

Y>>>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.

E>>Боюсь, что если без парсеров и DDL, то объем ручного программирования в конце-концов приведет к невозможности использования такого решения.


Y>ну можно на макросах...


E>>Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?


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


Just FYI http://agenda.cern.ch/fullAgenda.php?ida=a051238
см. "Fermilab trip report — C++, Reflex and the Standards Committee"
В двух словах — поступило предложение добавить reflection в стандарт языка.
будем внимательно следить за событиями
Re[6]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 17:37
Оценка:
Здравствуйте, hth, Вы писали:

hth>Just FYI http://agenda.cern.ch/fullAgenda.php?ida=a051238

hth>см. "Fermilab trip report — C++, Reflex and the Standards Committee"
hth>В двух словах — поступило предложение добавить reflection в стандарт языка.
hth>будем внимательно следить за событиями

пока они внесут в стандарт, а потом пока производители компиляторов реализуют...
чувствую придется и дальше велосипед свой дописывать...
... << RSDN@Home 1.1.3 stable >>
Re[5]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.05 18:43
Оценка:
Здравствуйте, yxiie, Вы писали:

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


Y>>>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец.

Y>>>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.

E>>Боюсь, что если без парсеров и DDL, то объем ручного программирования в конце-концов приведет к невозможности использования такого решения.


Y>ну можно на макросах...


Вообще-то я имел в виду нечто другое. Конечно, описывать сериализуемые атрибуты, явно назначая им строковые имена, плохо. Лучше, если строковые имена будут назначаться автоматически из C++ имени атрибута (через макрос, парсер или DDL). Более важный вопрос -- это вызов метода объекта через reflection. Вот как это предлагал Batiskaf:

typedef    TYPELIST_4(    const std_string&, 
                        unsigned char, 
                        const std_string&,
                        unsigned int )                ConstructorParamList;
typedef    Loki::Functor<    TheObject*, 
                        ConstructorParamList >            Constructor;

//В случае отстутствия конструктора с таким прототипом будет выброшено исключение 
//подобная стратегия применяется для всех запросов к метаклассу
Constructor    ctor = 
                        pClass->GetConstructor<    ConstructorParamList>();

//Создание экземпляра обьекта с вызовом полученного конструктора
TheObject* pObj = ctor("Vasya", 27, "London", 12 );


Вот эти вот описания ConstructorParamList и Constructor:
— во-первых, напрочь лишают нас преимуществ статической типизации. На момент компиляции этой инструкции компилятор не в состоянии проверить, есть ли у класса конструктор с таким набором параметров;
— во-вторых, изменение прототипа конструктора приведет к необходимости правки кода, вызывающего этот конструктор через reflection. Если таких фрагментов много, то очень высока вероятность того, что где-то мы забудем сделать исправления и получим run-time ошибку в самый неподходящий момент.

Для преодоления второй проблемы описания ConstructorParamList и Constructor можно сделать в каком-то заголовочном файле, в одном месте на весь проект. Но, эти объявления все равно окажутся оторванными от реального конструктора и компилятор не сможет проводить статическую проверку типов. Тогда возникает вопрос: а почему бы не сделать следующий логический шаг и не определить интерфейс фабрики:

class    MyClassNameIface
    {
    public :
        MyClassName *
        construct(
            const std::string &,
            unsigned char,
            const std::string &,
            unsigned int );
        ...
    };


И через reflection получать указатель на экземпляр, реализующий этот интерфейс?
Тогда мы получаем нормальную статическую типизации.

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

С доступом к атрибутам объектов ситуация не такая однозначная, как с методами. Хотя, изменять значение атрибута через reflection -- это нарушение принципов полиморфизма: может быть setter для этого атрибута выполняет хитрые преобразования или проверки, а мы их таким суровым образом обходим. Другое дело сериализация/десериализация. Ведь тогда мы, по сути, выполняем просто сохранение снимка объекта и восстановление объекта по снимку. Но и в этом случае reflection вырождается в сериализацию, для которой уже масса решений существует.

E>>Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?


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


Я бы не был столь категоричен:
1. Написание макросов или какого-то кода вручную черевато ошибками. И требует больших трудозатрат.
2. Запуск каких-либо дополнительных инструментов для генерации вспомогательного C++ кода -- это обычная практика. Так поступают и при работе с lex/flex/yacc/bison, и при работе с ANTLR, и при работе с Qt. При наличии нормального инструмента по управлению компиляцией это вообще не проблема (tmake для Qt скрывает от программиста детали преобразования ui-файлов в cpp, а cpp-файлов в moc).
3. С помощью внешних описаний схемы данных можно достигать таких возможностей, которые на уровне макросов в крайне сложно, если вообще возможно, реализовать. Например, поддержку необязательных атрибутов при сериализации. Т.е., если атрибут содержит значение по-умолчанию, то атрибут можно не сериализовать, что экономит и время и место.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 19:12
Оценка:
Здравствуйте, eao197, Вы писали:

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


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

var myObject;

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


speak for yourself. в том то и дело, что мне рефлексия не для сериализации нужна, а в первую очередь для удобного script-binding.

E>С доступом к атрибутам объектов ситуация не такая однозначная, как с методами.


да хрен с ними, с атрибутами. если сильно нужно, я бы мог и без них обойтись.

E>Хотя, изменять значение атрибута через reflection -- это нарушение принципов полиморфизма: может быть setter для этого атрибута выполняет хитрые преобразования или проверки, а мы их таким суровым образом обходим. Другое дело сериализация/десериализация. Ведь тогда мы, по сути, выполняем просто сохранение снимка объекта и восстановление объекта по снимку.


эх не знаю, это наверное только в сказке так — сделал снимок, и восстановил по нем

E>Но и в этом случае reflection вырождается в сериализацию, для которой уже масса решений существует.


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

E>>>Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?


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


E>Я бы не был столь категоричен:

E>1. Написание макросов или какого-то кода вручную черевато ошибками. И требует больших трудозатрат.
E>2. Запуск каких-либо дополнительных инструментов для генерации вспомогательного C++ кода -- это обычная практика. Так поступают и при работе с lex/flex/yacc/bison, и при работе с ANTLR, и при работе с Qt. При наличии нормального инструмента по управлению компиляцией это вообще не проблема (tmake для Qt скрывает от программиста детали преобразования ui-файлов в cpp, а cpp-файлов в moc).
E>3. С помощью внешних описаний схемы данных можно достигать таких возможностей, которые на уровне макросов в крайне сложно, если вообще возможно, реализовать. Например, поддержку необязательных атрибутов при сериализации. Т.е., если атрибут содержит значение по-умолчанию, то атрибут можно не сериализовать, что экономит и время и место.

мне не нужно таких масштабов. мне нужно просто сделать отображение иерархии.
у меня сейчас приложение — это динамическая отображенная именованая иерархия, части которой постоянно меняются. что-то загружается из xml, что-то генерируется в ран-тайм, где по имени можно оперировать любым объектом. вот такое мне и нужно, только уже готовое и отлаженое, и не надо меня переубеждать
... << RSDN@Home 1.1.3 stable >>
Re[7]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.03.05 21:15
Оценка:
Здравствуйте, yxiie, Вы писали:

<...>

Y>мне не нужно таких масштабов. мне нужно просто сделать отображение иерархии.

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

Ok. Просто стало понятно, что тебе необходимо.

Но я думаю, что тебе не reflection нужен, а интеграция скриптового языка и C++ кода. Может посмотреть, как это сделано в таких языках, как Python, Ruby (там, имхо, попроще, чем в Python), Lua?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 07.03.05 21:35
Оценка:
Здравствуйте, eao197, Вы писали:

E>Ok. Просто стало понятно, что тебе необходимо.


E>Но я думаю, что тебе не reflection нужен, а интеграция скриптового языка и C++ кода. Может посмотреть, как это сделано в таких языках, как Python, Ruby (там, имхо, попроще, чем в Python), Lua?


не совсем. мне не нужно ничего интегрировать, т.к. скрипт-язык сам будет частью системы, в этом то и прикол. если бы мне нужно было просто прикрутить скрипт-язык я бы просто взял boost.python или luabind и не парился. Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.
... << RSDN@Home 1.1.3 stable >>
Re[9]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.03.05 04:59
Оценка:
Здравствуйте, yxiie, Вы писали:

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


E>>Ok. Просто стало понятно, что тебе необходимо.


E>>Но я думаю, что тебе не reflection нужен, а интеграция скриптового языка и C++ кода. Может посмотреть, как это сделано в таких языках, как Python, Ruby (там, имхо, попроще, чем в Python), Lua?


Y>не совсем. мне не нужно ничего интегрировать, т.к. скрипт-язык сам будет частью системы, в этом то и прикол. если бы мне нужно было просто прикрутить скрипт-язык я бы просто взял boost.python или luabind и не парился. Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.


А ты можешь, если это не секрет, поделится своими идеями на этот счет? А то я, например, не очень понимаю такую вещь. Вот, допустим, в твоем скрипте есть строки:

MyObject my;
my.sayThis( "Hello, world!", Color::red );


Я не помнимаю, как для такого кода, с помощью решения Batiskaf-а ты сделаешь вызов метода C++ объекта. Ведь тебе придется в статике, в C++ тексте, написать что-то вроде:

typedef    TYPELIST_2(
        const std_string&, 
        unsigned int )
    SayThisParamList;
typedef    Loki::Functor< TheObject*, 
        SayThisParamList >
    SayThis;

SayThis m = pClass->GetMethod<void, SayThisParamList >( pObj, "sayThis" );
m();


Но, ведь ты заранее не можешь сам описать вызовы всех методов из всех доступных из скрипта классов. Если бы ты мог, то reflection тебе не потребовался бы.

Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 08.03.05 08:16
Оценка:
Здравствуйте, eao197, Вы писали:

E>А ты можешь, если это не секрет, поделится своими идеями на этот счет? А то я, например, не очень понимаю такую вещь. Вот, допустим, в твоем скрипте есть строки:


E>
E>MyObject my;
E>my.sayThis( "Hello, world!", Color::red );
E>


E>Я не помнимаю, как для такого кода, с помощью решения Batiskaf-а ты сделаешь вызов метода C++ объекта. Ведь тебе придется в статике, в C++ тексте, написать что-то вроде:


...

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


E>Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?


нет никаких длл. забыл, что у меня первым пунктом стоит портабельность?
как я вызову? просто нужно будет расширить этот код так, чтобы при регистрации метода он еще и добавлял информацию о параметрах метода, таким образом
у нас в ран-тайм будет полная сигнатура метода класса, по которой скрипту не составит труда найти нужный метод.
... << RSDN@Home 1.1.3 stable >>
Re[9]: Reflection for C++
От: Tonal- Россия www.promsoft.ru
Дата: 08.03.05 10:18
Оценка:
Здравствуйте, yxiie, Вы писали:
Y>Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.
По моему тут некоторое противоречие: или скорость выполнения и статический контроль типов, или скорость и прозрачность разработки в скриптовом языке.
Вез жертв тут не обойтись.
Когда я сталкивался с похожей задачей, была реализована отдельная "высокоуровнивая" иерархия специально для скриптования.
Мы её расширяли/изменяли по мере надобности.
Если вдруг обнаруживали часто встречающуюся или недостающую задачу.

Тут ещё играет роль тот фактор, что скрипты часто пишут конечные пользователи, у которых достаточно мало опыта как в написании программ, так и в отладке. А ядро системы всё-таки более квалифицированные програмеры.
Соответственно нужен более "надёжный" и "защищённый" от дурака язык. Понятно, что если одни и те же классы мы попытаемся использовать и там и там, получим либо утяжеление в C++ либо напряги в скрипте.

А как наиболее прозрачное решение можно посоветовать либо всё делать на COM/CORBA, либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.
... << RSDN@Home 1.1.4 beta 4 rev. 343>>
Re[10]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 08.03.05 10:43
Оценка:
Здравствуйте, Tonal-, Вы писали:

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

Y>>Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.
T>По моему тут некоторое противоречие: или скорость выполнения и статический контроль типов, или скорость и прозрачность разработки в скриптовом языке.
T>Вез жертв тут не обойтись.
почему же противоречие? когда работаем на С++ имеем скорость и контроль. когда на скриптовом языке — имеем удобность и прозрачность.

T>Когда я сталкивался с похожей задачей, была реализована отдельная "высокоуровнивая" иерархия специально для скриптования.

T>Мы её расширяли/изменяли по мере надобности.
T>Если вдруг обнаруживали часто встречающуюся или недостающую задачу.

у меня щас тоже так, и где я говорил, что я против такого?

T>Тут ещё играет роль тот фактор, что скрипты часто пишут конечные пользователи, у которых достаточно мало опыта как в написании программ, так и в отладке. А ядро системы всё-таки более квалифицированные програмеры.


какой еще фактор? это основная причина, по которой я все это дело затеял.

T>Соответственно нужен более "надёжный" и "защищённый" от дурака язык. Понятно, что если одни и те же классы мы попытаемся использовать и там и там, получим либо утяжеление в C++ либо напряги в скрипте.


скрипт язык будет клоном JavaScript.

T>А как наиболее прозрачное решение можно посоветовать либо всё делать на COM/CORBA,


не портабельно, а это условие номер 1.

T>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.


слишком сложный скрипт-язык.
... << RSDN@Home 1.1.3 stable >>
Re[11]: Reflection for C++
От: hth  
Дата: 08.03.05 10:50
Оценка: :))
Здравствуйте, yxiie, Вы писали:


T>>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.


Y>слишком сложный скрипт-язык.


C++ — сложный, согласен,
но C — очень простой, какой еще проще?

Если нужна простата — пользуй C!
Re[12]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 08.03.05 10:57
Оценка:
Здравствуйте, hth, Вы писали:

T>>>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.


Y>>слишком сложный скрипт-язык.


hth>C++ — сложный, согласен,

hth>но C — очень простой,

простой для тебя, для меня, для программиста.
а скрипты предполагается будут писать непрограммисты.

hth>какой еще проще?


я уже сказал — JavaScript. практика использования Macromedia Flash показывает, что дизайнеры могут вполне сносно его использовать (напомню ActionScript из Flash — по сути обрезанный JavaScript)

hth>Если нужна простата — пользуй C!


нет уж спасибо
... << RSDN@Home 1.1.3 stable >>
Re[13]: Reflection for C++
От: hth  
Дата: 08.03.05 11:10
Оценка:
Здравствуйте, yxiie, Вы писали:

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


T>>>>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.


Y>>>слишком сложный скрипт-язык.


hth>>C++ — сложный, согласен,

hth>>но C — очень простой,

Y>простой для тебя, для меня, для программиста.

Y>а скрипты предполагается будут писать непрограммисты.

hth>>какой еще проще?


Y>я уже сказал — JavaScript. практика использования Macromedia Flash показывает, что дизайнеры могут вполне сносно его использовать (напомню ActionScript из Flash — по сути обрезанный JavaScript)


hth>>Если нужна простата — пользуй C!


Y>нет уж спасибо


потушим так любимый ламерами и льюзерами пионерский костер!
Re[11]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 06:14
Оценка:
Здравствуйте, yxiie, Вы писали:

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


E>>А ты можешь, если это не секрет, поделится своими идеями на этот счет? А то я, например, не очень понимаю такую вещь. Вот, допустим, в твоем скрипте есть строки:


E>>
E>>MyObject my;
E>>my.sayThis( "Hello, world!", Color::red );
E>>


E>>Я не помнимаю, как для такого кода, с помощью решения Batiskaf-а ты сделаешь вызов метода C++ объекта. Ведь тебе придется в статике, в C++ тексте, написать что-то вроде:


Y>...


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


E>>Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?


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


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

Y>как я вызову? просто нужно будет расширить этот код так, чтобы при регистрации метода он еще и добавлял информацию о параметрах метода, таким образом


O! Т.е., задача на самом деле сужается. Т.е. у тебя есть необходимость вызывать из скрипта методы не всех объектов, а только специально предназначенных для этого. Далее выяснится, что и у этих объектов нужно вызывать не все методы. Или я не прав?

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


Найти-то ладно, мне интересно, что ты дальше делать будешь

Вот пусть у тебя будет метод с сигнатурой void sayThis( const std::string&, unsigned int ). В скрипте у тебя будет два объекта: строка "Hello, World" и константа Color::red. Для того, чтобы хранить значения этих объектов, тебе потребуется иметь два C++ объекта, например класса ScalarExpression. Так вот, мне интересно:

— интерпритатор скрипта умеет работать с элемента скрипта. Он знает, как плодить и работать со ScalarExpression;
— интерпритатор в месте вызова sayThis определяет типы параметров, строит сигнатуру и по ней находит указатель на метод sayThis;
— как дальше должен вести себя интерпритатор, чтобы вызвать метод sayThis?

Ведь, когда интерпритатор компилировался, он ничего не знал про метод sayThis. И в его C++ коде не было конструкции:
void (*sayThisPtr)( const std::string &, unsigned int ) = ...;
(*sayThisPtr)( firstArg.value(), secondArg.value() );


ИМХО, здесь у тебя два варианта:

1. Реализовать возможность вызова метода вручную запихивая параметры в стек и используюя ассемблерную инструкцию call. Но тогда о переносимости можно забыть.

2. Самому делать proxy для вызова методов объектов, например, в виде:
void
sayThisProxy( const std::vector< Expression * > & args, MyObject * object )
    {
        StringScalarExpression * first = dynamic_cast< StringScalarExpression * >( args[ 0 ] );
        UintScalarExpression * second = dynamic_cast< UintScalarExpression * >( args[ 1 ] );
        
        object->sayThis( first, second );
    }


ИМХО, создание таких proxy -- это не есть механизм reflection.

Более того, такие задачи уже были решены в языках типа Ruby, Python, Lua, ... Есть даже проект Swig, который, насколько я его понимаю, значительно упрощает интеграцию скриптовых языков с языками типа C/C++, C#, Java. Может тебе в ту сторону посмотреть?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 08:06
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?


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


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


любая игровая консоль...

Y>>как я вызову? просто нужно будет расширить этот код так, чтобы при регистрации метода он еще и добавлял информацию о параметрах метода, таким образом


E>O! Т.е., задача на самом деле сужается. Т.е. у тебя есть необходимость вызывать из скрипта методы не всех объектов, а только специально предназначенных для этого. Далее выяснится, что и у этих объектов нужно вызывать не все методы. Или я не прав?


ну да. вызывать нужно только зарегистрированные методы зарегистрированных объектов.

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


E>Найти-то ладно, мне интересно, что ты дальше делать будешь


E>Вот пусть у тебя будет метод с сигнатурой void sayThis( const std::string&, unsigned int ). В скрипте у тебя будет два объекта: строка "Hello, World" и константа Color::red. Для того, чтобы хранить значения этих объектов, тебе потребуется иметь два C++ объекта, например класса ScalarExpression. Так вот, мне интересно:


E>- интерпритатор скрипта умеет работать с элемента скрипта. Он знает, как плодить и работать со ScalarExpression;

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

E>Ведь, когда интерпритатор компилировался, он ничего не знал про метод sayThis. И в его C++ коде не было конструкции:

E>
E>void (*sayThisPtr)( const std::string &, unsigned int ) = ...;
E>(*sayThisPtr)( firstArg.value(), secondArg.value() );
E>


E>ИМХО, здесь у тебя два варианта:


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


E>2. Самому делать proxy для вызова методов объектов, например, в виде:

E>
E>void
E>sayThisProxy( const std::vector< Expression * > & args, MyObject * object )
E>    {
E>        StringScalarExpression * first = dynamic_cast< StringScalarExpression * >( args[ 0 ] );
E>        UintScalarExpression * second = dynamic_cast< UintScalarExpression * >( args[ 1 ] );
        
E>        object->sayThis( first, second );
E>    }
E>


да, скорее всего второй вариант, только зачем самому делать прокси? у байндера к методу будет ф-ция, которая будет
принимать параметры скрипта и на основе их формировать вызов С++ метода.

E>ИМХО, создание таких proxy -- это не есть механизм reflection.


не понял, объясни, что ты хочешь сказать.

E>Более того, такие задачи уже были решены в языках типа Ruby, Python, Lua, ...


такие, да, но не все. по сути либы типа boost.python делают только байнд. мне же скорее нужно что-то среднее между байндом и полноценной рефлексией.

E>Есть даже проект Swig, который, насколько я его понимаю, значительно упрощает интеграцию скриптовых языков с языками типа C/C++, C#, Java. Может тебе в ту сторону посмотреть?


щас посмотрю, не помню, может проморгал его...
... << RSDN@Home 1.1.3 stable >>
Re[13]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 08:14
Оценка:
Здравствуйте, yxiie, Вы писали:

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


E>>>>Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?


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


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


Y>любая игровая консоль...


Ну не любая
На XBox, например, Windows стоит. Там DLL-ки точно есть
А под какими OS, например, Sony PS работает, я не знаю.

<...>

E>>2. Самому делать proxy для вызова методов объектов, например, в виде:

E>>
E>>void
E>>sayThisProxy( const std::vector< Expression * > & args, MyObject * object )
E>>    {
E>>        StringScalarExpression * first = dynamic_cast< StringScalarExpression * >( args[ 0 ] );
E>>        UintScalarExpression * second = dynamic_cast< UintScalarExpression * >( args[ 1 ] );
        
E>>        object->sayThis( first, second );
E>>    }
E>>


Y>да, скорее всего второй вариант, только зачем самому делать прокси? у байндера к методу будет ф-ция, которая будет

Y>принимать параметры скрипта и на основе их формировать вызов С++ метода.

Но как делать вызов? Мне просто интересно код такого байндера увидеть.

E>>ИМХО, создание таких proxy -- это не есть механизм reflection.


Y>не понял, объясни, что ты хочешь сказать.


Ok. Но мне нужно некоторое время, чтобы восстановить в памяти информацию по reflection в Java. Тогда попробую объяснить.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 08:27
Оценка:
Здравствуйте, eao197, Вы писали:

Y>>любая игровая консоль...


E>Ну не любая

E>На XBox, например, Windows стоит. Там DLL-ки точно есть

на Xbox как раз точно нет, насчет остальных точно не скажу.

E>А под какими OS, например, Sony PS работает, я не знаю.


Sony Playstation 2 OS = Sony Linux
Nintendo GameCube OS = Dolphin Mac OS какая-то

Y>>да, скорее всего второй вариант, только зачем самому делать прокси? у байндера к методу будет ф-ция, которая будет

Y>>принимать параметры скрипта и на основе их формировать вызов С++ метода.

E>Но как делать вызов? Мне просто интересно код такого байндера увидеть.


ну дак посмотри у Batiskaf-a там же все открыто, или я не понял, что именно ты хочешь увидеть?
... << RSDN@Home 1.1.3 stable >>
Re[15]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 08:33
Оценка:
Здравствуйте, yxiie, Вы писали:

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


Y>>>любая игровая консоль...


E>>Ну не любая

E>>На XBox, например, Windows стоит. Там DLL-ки точно есть

Y>на Xbox как раз точно нет, насчет остальных точно не скажу.


Windows без DLL?
Век живи, век учись. А где про это прочитать можно?

E>>А под какими OS, например, Sony PS работает, я не знаю.


Y>Sony Playstation 2 OS = Sony Linux


Ну под Linux-ом-то DLL-ки точно должны быть.

Y>Nintendo GameCube OS = Dolphin Mac OS какая-то


Y>>>да, скорее всего второй вариант, только зачем самому делать прокси? у байндера к методу будет ф-ция, которая будет

Y>>>принимать параметры скрипта и на основе их формировать вызов С++ метода.

E>>Но как делать вызов? Мне просто интересно код такого байндера увидеть.


Y>ну дак посмотри у Batiskaf-a там же все открыто, или я не понял, что именно ты хочешь увидеть?


yxiie, я же уже спрашивал раньше. Мне интересно, как появится такой код:
typedef    TYPELIST_2(
        const std_string&, 
        unsigned int )
    SayThisParamList;
typedef    Loki::Functor< TheObject*, 
        SayThisParamList >
    SayThis;

SayThis m = pClass->GetMethod<void, SayThisParamList >( pObj, "sayThis" );
m();


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

Кстати, из скрипта ведь можно будет не все C++ объекты инстанциировать? А только специально для этого предназначенные.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 08:41
Оценка:
Здравствуйте, eao197, Вы писали:

Y>>на Xbox как раз точно нет, насчет остальных точно не скажу.


E>Windows без DLL?

E>Век живи, век учись. А где про это прочитать можно?

набери в гугле что-то типа xbox development, в любом описании характеристик Xbox все должно быть.

E>>>А под какими OS, например, Sony PS работает, я не знаю.


Y>>Sony Playstation 2 OS = Sony Linux


E>Ну под Linux-ом-то DLL-ки точно должны быть.


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

Y>>ну дак посмотри у Batiskaf-a там же все открыто, или я не понял, что именно ты хочешь увидеть?


E>yxiie, я же уже спрашивал раньше. Мне интересно, как появится такой код:

E>
E>typedef    TYPELIST_2(
E>        const std_string&, 
E>        unsigned int )
E>    SayThisParamList;
E>typedef    Loki::Functor< TheObject*, 
E>        SayThisParamList >
E>    SayThis;

E>SayThis m = pClass->GetMethod<void, SayThisParamList >( pObj, "sayThis" );
E>m();
E>


E>Его что, ручками нужно написать?

E>Для каждого метода, который можно вызывать из скрипта?

а зачем такой код? такой код будет использоваться только в С++, для скрипта будет скорее что-то типа

BindedMethod->Invoke(obj, params);

E>Кстати, из скрипта ведь можно будет не все C++ объекты инстанциировать? А только специально для этого предназначенные.


те, которые зарегистрированы, да.
... << RSDN@Home 1.1.3 stable >>
Re[17]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 08:49
Оценка:
Здравствуйте, yxiie, Вы писали:

E>>yxiie, я же уже спрашивал раньше. Мне интересно, как появится такой код:

E>>
E>>typedef    TYPELIST_2(
E>>        const std_string&, 
E>>        unsigned int )
E>>    SayThisParamList;
E>>typedef    Loki::Functor< TheObject*, 
E>>        SayThisParamList >
E>>    SayThis;

E>>SayThis m = pClass->GetMethod<void, SayThisParamList >( pObj, "sayThis" );
E>>m();
E>>


E>>Его что, ручками нужно написать?

E>>Для каждого метода, который можно вызывать из скрипта?

Y>а зачем такой код? такой код будет использоваться только в С++, для скрипта будет скорее что-то типа


Y>BindedMethod->Invoke(obj, params);


Так вот и я об этом же. Что из скрипта будет вызываться некий Invoke, а уже в Invoke будет код, который приведен выше. Так?

E>>Кстати, из скрипта ведь можно будет не все C++ объекты инстанциировать? А только специально для этого предназначенные.


Y>те, которые зарегистрированы, да.


Так вот, если объекты, которые ты делаешь доступными для скрипта и методы этих объектов заранее определены, то зачем огород с reflection?

Почему просто не сделать BindedMethod->Invoke оберткой сразу над конкретным C++ классом/интерфейсом? А уже нужные тебе C++ классы/интерфейсы инстанциировать посредством фабрики?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 09:09
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>yxiie, я же уже спрашивал раньше. Мне интересно, как появится такой код:

E>>>
E>>>typedef    TYPELIST_2(
E>>>        const std_string&, 
E>>>        unsigned int )
E>>>    SayThisParamList;
E>>>typedef    Loki::Functor< TheObject*, 
E>>>        SayThisParamList >
E>>>    SayThis;

E>>>SayThis m = pClass->GetMethod<void, SayThisParamList >( pObj, "sayThis" );
E>>>m();
E>>>


E>>>Его что, ручками нужно написать?

E>>>Для каждого метода, который можно вызывать из скрипта?

Y>>а зачем такой код? такой код будет использоваться только в С++, для скрипта будет скорее что-то типа


Y>>BindedMethod->Invoke(obj, params);


E>Так вот и я об этом же. Что из скрипта будет вызываться некий Invoke, а уже в Invoke будет код, который приведен выше. Так?


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

E>>>Кстати, из скрипта ведь можно будет не все C++ объекты инстанциировать? А только специально для этого предназначенные.


Y>>те, которые зарегистрированы, да.


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


E>Почему просто не сделать BindedMethod->Invoke оберткой сразу над конкретным C++ классом/интерфейсом? А уже нужные тебе C++ классы/интерфейсы инстанциировать посредством фабрики?


потому, что если мы обойдемся только байндом, то из скрипта мы сможем оперировать объектами С++, а из С++ оперировать объектами скрипта — нет.
... << RSDN@Home 1.1.3 stable >>
Re[19]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 09:36
Оценка:
Здравствуйте, yxiie, Вы писали:

E>>Так вот и я об этом же. Что из скрипта будет вызываться некий Invoke, а уже в Invoke будет код, который приведен выше. Так?


Y>зачем? в байнд-объекте мы уже имеем адрес метода и информацию о параметрах. единственное, что нужно — обработать и преобразовать переданные

Y>скриптом параметры в подходящие для этого метода и сделать вызов.

Но КАК? (Торможу я что-то). Приведи, пожалуйста код по организации вызова метода, сигнатура которого заранее была неизвестна.

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


E>>Почему просто не сделать BindedMethod->Invoke оберткой сразу над конкретным C++ классом/интерфейсом? А уже нужные тебе C++ классы/интерфейсы инстанциировать посредством фабрики?


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


Ну это ты зря. Это уж как напишешь.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 09:48
Оценка:
Здравствуйте, eao197, Вы писали:

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


E>>>Так вот и я об этом же. Что из скрипта будет вызываться некий Invoke, а уже в Invoke будет код, который приведен выше. Так?


Y>>зачем? в байнд-объекте мы уже имеем адрес метода и информацию о параметрах. единственное, что нужно — обработать и преобразовать переданные

Y>>скриптом параметры в подходящие для этого метода и сделать вызов.

E>Но КАК? (Торможу я что-то). Приведи, пожалуйста код по организации вызова метода, сигнатура которого заранее была неизвестна.


почему же неизвестна? посмотри в исходниках Batiskaf-a как у него сделана регистрация метода — BindMethod. если все-равно будет неясно, тогда попробую объяснить.

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


E>>>Почему просто не сделать BindedMethod->Invoke оберткой сразу над конкретным C++ классом/интерфейсом? А уже нужные тебе C++ классы/интерфейсы инстанциировать посредством фабрики?


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


E>Ну это ты зря. Это уж как напишешь.


ну и какая тогда будет разница между такими наворотами продвинутого байнда и рефлексией?
... << RSDN@Home 1.1.3 stable >>
Re[21]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 10:06
Оценка:
Здравствуйте, yxiie, Вы писали:

E>>Но КАК? (Торможу я что-то). Приведи, пожалуйста код по организации вызова метода, сигнатура которого заранее была неизвестна.


Y>почему же неизвестна? посмотри в исходниках Batiskaf-a как у него сделана регистрация метода — BindMethod. если все-равно будет неясно, тогда попробую объяснить.


Объясняй сразу. Ведь мне не интересны внутренности регистрации метода через BindMethod. Мне интересно, как ты будешь через reflection вызывать метод, сигнатуру которого ты до этого не знал. Ведь в примере, который привел Batiskaf показано, что сигнатура должна быть известна (привел бы оттуда фрагмент с GetMethod, но у того метода простая сигнатура):

typedef    TYPELIST_4(    const std_string&, 
                        unsigned char, 
                        const std_string&,
                        unsigned int )                ConstructorParamList;
typedef    Loki::Functor<    TheObject*, 
                        ConstructorParamList >            Constructor;

//В случае отстутствия конструктора с таким прототипом будет выброшено исключение 
//подобная стратегия применяется для всех запросов к метаклассу
Constructor    ctor = 
                        pClass->GetConstructor<    ConstructorParamList>();

//Создание экземпляра обьекта с вызовом полученного конструктора
TheObject* pObj = ctor("Vasya", 27, "London", 12 );


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 10:19
Оценка:
Здравствуйте, eao197, Вы писали:

E>Объясняй сразу. Ведь мне не интересны внутренности регистрации метода через BindMethod. Мне интересно, как ты будешь через reflection вызывать метод, сигнатуру которого ты до этого не знал. Ведь в примере, который привел Batiskaf показано, что сигнатура должна быть известна (привел бы оттуда фрагмент с GetMethod, но у того метода простая сигнатура):


...

лучше бы ты посмотрел. там у него BindMethod — это переопрделенное имя:

...
            template<    typename RType, 
                        typename Param1,
                        typename Param2,
                        typename Obj
            >void    BindMethod(    const std_string&    name,
                                RType    (Obj::*method)(    Param1, 
                                                        Param2))
...

            template<    typename RType, 
                        typename Param1,
                        typename Param2,
                        typename Param3,
                        typename Obj
            >void    BindMethod(    const std_string&    name,
                                RType    (Obj::*method)(    Param1, 
                                                        Param2, 
                                                        Param3))
...
            template<    typename RType, 
                        typename Param1,
                        typename Param2,
                        typename Param3,
                        typename Param4,
                        typename Param5,
                        typename Param6,
                        typename Obj
            >void    BindMethod(    const std_string&    name,
                                RType    (Obj::*method)(    Param1, 
                                                        Param2, 
                                                        Param3, 
                                                        Param4, 
                                                        Param5, 
                                                        Param6))


таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать
параметры из скрипта и на основе их делать вызов.
... << RSDN@Home 1.1.3 stable >>
Re[14]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 10:24
Оценка:
Здравствуйте, eao197, Вы писали:

E>>>ИМХО, создание таких proxy -- это не есть механизм reflection.


Y>>не понял, объясни, что ты хочешь сказать.


E>Ok. Но мне нужно некоторое время, чтобы восстановить в памяти информацию по reflection в Java. Тогда попробую объяснить.


Просто, как я понял твою задачу, тебе нужна только одна возможность из reflection -- вызов метода. Все остальное ты проигнорируешь.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 10:27
Оценка:
Здравствуйте, eao197, Вы писали:

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


опиши мне все возможности reflection и я скажу, какие я проигнорирую, какие нет.
... << RSDN@Home 1.1.3 stable >>
Re[23]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 10:27
Оценка:
Здравствуйте, yxiie, Вы писали:

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


E>>Объясняй сразу. Ведь мне не интересны внутренности регистрации метода через BindMethod. Мне интересно, как ты будешь через reflection вызывать метод, сигнатуру которого ты до этого не знал. Ведь в примере, который привел Batiskaf показано, что сигнатура должна быть известна (привел бы оттуда фрагмент с GetMethod, но у того метода простая сигнатура):


Y>...


Y>лучше бы ты посмотрел. там у него BindMethod — это переопрделенное имя:


Y>
Y>...
Y>            template<    typename RType, 
Y>                        typename Param1,
Y>                        typename Param2,
Y>                        typename Obj
            >>void    BindMethod(    const std_string&    name,
Y>                                RType    (Obj::*method)(    Param1, 
Y>                                                        Param2))
...
Y>


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

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

Y>параметры из скрипта и на основе их делать вызов
.

Как???
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[24]: Reflection for C++
От: sch  
Дата: 09.03.05 10:38
Оценка: :)
E>Как???

void *fptr=find_function_ptr(function_name);
int param,size,params_size;
while(get_next_param(param,size)) {
    asm {
        mov edi,esp

        sub esp,size

        mov ecx,size
        mov esi,param
        cld
        rep stosb
    }

    params_size+=size;
}

asm {
    call fptr
    add esp,params_size
}


Как сделать это на C++ не представляю...
Re[25]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 10:44
Оценка:
Здравствуйте, sch, Вы писали:

E>>Как???


sch>
sch>void *fptr=find_function_ptr(function_name);
sch>int param,size,params_size;
sch>while(get_next_param(param,size)) {
sch>    asm {
sch>        mov edi,esp

sch>        sub esp,size

sch>        mov ecx,size
sch>        mov esi,param
sch>        cld
sch>        rep stosb
sch>    }

sch>    params_size+=size;
sch>}

sch>asm {
sch>    call fptr
sch>    add esp,params_size
sch>}
sch>


sch>Как сделать это на C++ не представляю...


Так вот и я о том же!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Reflection for C++
От: sch  
Дата: 09.03.05 10:49
Оценка:
E>Так вот и я о том же!
Интересно, а вот так получится? Только придется варианты использовать, а это уже медленно...

class abstract_function {
public:
    virtual ~abstract_function()=0 {}
    virtual variant call(vector<variant> args)=0;
};

template<class R,class P1>
class function1: public abstract_function {
public:
    R (*fptr)(P1 p1);
    variant call(vector<variant> args) {
        return fptr((P1) args[0]);
    }
}

template<class R,class P1,class P2>
class function2: public abstract_function {
public:
    R (*fptr)(P1 p1,P2 p2);
    variant call(vector<variant> args) {
        return fptr((P1) args[0], (P2) args[1]);
    }
}
Re[24]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 10:52
Оценка:
Здравствуйте, eao197, Вы писали:

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


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

Y>>параметры из скрипта и на основе их делать вызов
.

E>Как???



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

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

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

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


конечно это все быстрый набросок, но надеюсь идея ясна.
... << RSDN@Home 1.1.3 stable >>
Re[27]: Reflection for C++
От: Seriously Serious  
Дата: 09.03.05 10:54
Оценка:
Здравствуйте, sch, Вы писали:

E>>Так вот и я о том же!

sch>Интересно, а вот так получится? Только придется варианты использовать, а это уже медленно...
<...>

Получится. А чем variant медленно?
Re[25]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 10:57
Оценка:
Здравствуйте, yxiie, Вы писали:

ошибочек пару исправил:

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:public InvokeFromScript {
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>// тут сохраняем InvokeFromScript2<Rtype, Param1, Param2, Obj>(method)
Y>...                                                        
                                                        

Y>
... << RSDN@Home 1.1.3 stable >>
Re[28]: Reflection for C++
От: sch  
Дата: 09.03.05 10:58
Оценка:
SS>Получится. А чем variant медленно?
Это мой маленький пунктик, если я где вижу лишний malloc() то меня тут же начинает передергивать
Re[29]: Reflection for C++
От: Seriously Serious  
Дата: 09.03.05 11:00
Оценка:
Здравствуйте, sch, Вы писали:

SS>>Получится. А чем variant медленно?

sch>Это мой маленький пунктик, если я где вижу лишний malloc() то меня тут же начинает передергивать

???
где?
Re[30]: Reflection for C++
От: sch  
Дата: 09.03.05 11:02
Оценка:
SS>где?
Это я пример привел такой, абстрактный так сказать.
Все конечно зависит от реализации variant, возможно есть другое решение?
Re[25]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 11:03
Оценка:
Здравствуйте, yxiie, Вы писали:

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


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


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

Y>>>параметры из скрипта и на основе их делать вызов
.

E>>Как???


Y>
...
Y>


Y>конечно это все быстрый набросок, но надеюсь идея ясна.


Да, что-то такое я предполагал с самого начала.

ИМХО, в системе интеграции Ruby с C гораздо проще все сделано. "Чего только русские не придумают, чтобы нормальные дороги не строить"
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 11:04
Оценка:
Здравствуйте, yxiie, Вы писали:

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


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


Y>опиши мне все возможности reflection и я скажу, какие я проигнорирую, какие нет.


Вот, коротко, что об этом говорится в JDK:

Reflection enables Java code to discover information about the fields, methods and constructors of loaded classes, and to use reflected fields, methods, and constructors to operate on their underlying counterparts on objects, within security restrictions. The API accommodates applications that need access to either the public members of a target object (based on its runtime class) or the members declared by a given class.


ИМХО, доступ к атрибутам тебе не потребуется.

Кстати, можешь посмотреть там еще и Dynamic Proxy. Вся мошь этого в Java проявляется из-за того, что в классе Method есть метод invoke, который получает список аргументов в виде Object[] (нетипизированный!). Как в C++ этого достичь портабильным способом?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 11:15
Оценка:
Здравствуйте, eao197, Вы писали:

Y>>опиши мне все возможности reflection и я скажу, какие я проигнорирую, какие нет.


E>Вот, коротко, что об этом говорится в JDK:

E>

E>Reflection enables Java code to discover information about the fields, methods and constructors of loaded classes, and to use reflected fields, methods, and constructors to operate on their underlying counterparts on objects, within security restrictions. The API accommodates applications that need access to either the public members of a target object (based on its runtime class) or the members declared by a given class.


E>ИМХО, доступ к атрибутам тебе не потребуется.


почему? по крайней мере не помешает. особенно при отладке не выходя в IDE-debugger.

E>Кстати, можешь посмотреть там еще и Dynamic Proxy. Вся мошь этого в Java проявляется из-за того, что в классе Method есть метод invoke, который получает список аргументов в виде Object[] (нетипизированный!). Как в C++ этого достичь портабильным способом?


я с жавой близко не знаком, так что ничего сказать не могу.
... << RSDN@Home 1.1.3 stable >>
Re[18]: Reflection for C++
От: SleepyDrago Украина  
Дата: 09.03.05 18:09
Оценка: +1
Здравствуйте, yxiie:

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

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

wbr

зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор
Re[19]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 18:26
Оценка:
Здравствуйте, SleepyDrago, Вы писали:

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


SD>имхо вы хотите того чего не нужно никому и никогда.

SD>зачем тут нужна рефлексия?

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

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

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

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

SD>после этого юзер может скриптить сколько угодно.

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

SD>wbr


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


честно говоря я абсолютно не понял, что вы хотели сказать
это замечание? возражение? уточнение?
... << RSDN@Home 1.1.3 stable >>
Re[20]: Reflection for C++
От: SleepyDrago Украина  
Дата: 09.03.05 18:43
Оценка:
Здравствуйте, yxiie, Вы писали:

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


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


SD>>имхо вы хотите того чего не нужно никому и никогда.

SD>>зачем тут нужна рефлексия?

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


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

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

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


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

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

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

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

wbr
Re[21]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 18:57
Оценка:
Здравствуйте, SleepyDrago, Вы писали:

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

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

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

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

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

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

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

я ведь уже упоминал — для использования в разработке игр, если сделать правильно — позволит серьезно упростить процес разработки и немало сэкономить за счет того, что часть игры смогут писать люди без глубоких знаний C++.
... << RSDN@Home 1.1.3 stable >>
Re[22]: Reflection for C++
От: SleepyDrago Украина  
Дата: 09.03.05 19:52
Оценка:
Здравствуйте, 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
Re[23]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 20:04
Оценка:
Здравствуйте, 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 >>
Re[24]: Reflection for C++
От: Аноним  
Дата: 09.03.05 21:09
Оценка:
Здравствуйте, yxiie, Вы писали:

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


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

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

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

wbr
зы поменьше эмоций.
Мне самому нужно нечто подобное так что "удачи!".
Re[25]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 09.03.05 21:22
Оценка:
Здравствуйте, <Аноним>, Вы писали:

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


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


А>Доктор ! где здесь рефлексия ?

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

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

А>wbr

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

если содержание сообщений не будет вилять туда-сюда, от DIA до LUA, я не буду огорчаться по поводу невозможности аргументированно ответить
... << RSDN@Home 1.1.3 stable >>
Re[24]: Reflection for C++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 21:49
Оценка:
Здравствуйте, yxiie, Вы писали:

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


Y>какие парсеры, какой DIA — у меня первым пунктом стоит портабельность, а парсеры — это не мой стиль.

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

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

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

Если что-то получится и можно будет озвучить результаты -- поделись впечатлениями, ладно?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[26]: Reflection for C++
От: SleepyDrago Украина  
Дата: 09.03.05 22:00
Оценка:
Здравствуйте, yxiie, Вы писали:

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


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


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

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


А>>Доктор ! где здесь рефлексия ?

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

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

Y>приведи мне твое определение рефлексии...

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

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

?

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

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


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

wbr
Re: Reflection for C++: если уж это для разработки игр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.03.05 22:31
Оценка:
Здравствуйте, 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>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Reflection for C++: если уж это для разработки игр
От: sch  
Дата: 09.03.05 22:38
Оценка:
Хотелось бы вернуть обсуждение в более конструктивное русло.
Итак, у нас есть структуры, описывающие методы и поля. Чтобы дать возможность обратиться к этим полям и методам, мы должны сделать некий map, один на каждый класс, в котором мы будем регистрировать метаданные, после чего обращаться к ним через map. Но вот меня интересует следующий вопрос: ведь метаданные статичны, однако мы будем создавать их как минимум один раз для каждого класса. Хотелось бы получить статичный метод вызова, который бы решал этот вопрос более эффективынм, быстрым и надежным путем.
Re[3]: Reflection for C++: вообще
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.03.05 05:24
Оценка: 7 (2) +1
Здравствуйте, 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 (Проект сериализации &mdash; 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>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Reflection for C++: вообще
От: yxiie Украина www.enkord.com
Дата: 10.03.05 08:14
Оценка:
Здравствуйте, 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 >>
Re[2]: Reflection for C++: если уж это для разработки игр
От: yxiie Украина www.enkord.com
Дата: 10.03.05 08:14
Оценка:
Здравствуйте, eao197, Вы писали:

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


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

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


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

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


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

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


смотрел

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


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

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


ну, я стараюсь совмещать приятное с полезным
... << RSDN@Home 1.1.3 stable >>
Re[25]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 10.03.05 08:14
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


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

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


не думаю, что скоро это будет — я пока присматриваюсь, но если будет что — озвучу.
... << RSDN@Home 1.1.3 stable >>
Re[3]: Reflection for C++: если уж это для разработки игр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.03.05 08:53
Оценка:
Здравствуйте, yxiie, Вы писали:

<...>

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


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

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


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


Думаю, что это не надолго.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Reflection for C++: вообще
От: sch  
Дата: 10.03.05 08:57
Оценка: 7 (1)
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()));
}
};
Re[6]: Reflection for C++: вообще
От: yxiie Украина www.enkord.com
Дата: 10.03.05 09:01
Оценка:
Здравствуйте, sch, Вы писали:

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


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

Y>>

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

Y>>?

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

...

да нет, тут наверное что-то другое, т.к. такое решение есть и у Batiskaf-a а мы это уже давно обсудили.
... << RSDN@Home 1.1.3 stable >>
Re[5]: Reflection for C++: вообще
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.03.05 09:20
Оценка:
Здравствуйте, 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>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: Reflection for C++
От: Batiskaf Израиль http://www.mult.ru/
Дата: 10.03.05 15:39
Оценка:
Здравствуйте, 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.

Хотя так не долго и до джавы со смолтоком дожиться, от лукавого это все
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[26]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 10.03.05 16:26
Оценка:
Здравствуйте, Batiskaf, Вы писали:

Y>>конечно это все быстрый набросок, но надеюсь идея ясна.

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

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

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


возможно, но на целевых платформах — С++ это потолок, и то с ограниченными возможностями (часто нету exceptions и rtti). так что если жаву придется изобретать — никуда не денешься, но я думаю до этого не дойдет если подойти без фанатизма, то все должно получится.
... << RSDN@Home 1.1.3 stable >>
Re[27]: Reflection for C++
От: Batiskaf Израиль http://www.mult.ru/
Дата: 11.03.05 19:16
Оценка:
Здравствуйте, yxiie, Вы писали:

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


Y>>>конечно это все быстрый набросок, но надеюсь идея ясна.

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

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



А что мешает использовать не только для вдохновения? С коментариями у меня на самом деле не сложилось, но если будут заинтересованные то это можно устроить, открыт к обсуждению любых предложений и идей, правда времени маловато, если кто то готов потратить свои драгоценные моменты жизни на эту идею, так за это слава и почет ждет этого великого програмиста.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[28]: Reflection for C++
От: yxiie Украина www.enkord.com
Дата: 11.03.05 19:50
Оценка:
Здравствуйте, Batiskaf, Вы писали:

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


B>А что мешает использовать не только для вдохновения? С коментариями у меня на самом деле не сложилось, но если будут заинтересованные то это можно устроить, открыт к обсуждению любых предложений и идей, правда времени маловато, если кто то готов потратить свои драгоценные моменты жизни на эту идею, так за это слава и почет ждет этого великого програмиста.


мешает то, что код не поддерживается. вы это написали когда-то и забыли, а я если и буду использовать это — то использовать в коммерческом проекте, придется тесно работать с библиотекой и лбом сталкиватся со всеми проблемами, а т.к. либа не поддерживается — искать и фиксить все баги придется самому. поэтому проще написать свое точно зная что где происходит. плюс мне придется расширять ее — делать динамический вызов методов, также придется переводить на boost и.т.д.
... << RSDN@Home 1.1.3 stable >>