Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания.
Интересует библиотека как можно более удовлетворяющая требования в таком порядке:
Здравствуйте, yxiie, Вы писали:
Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания. Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:
Y>1. Портабельная Y>2. Быстрая Y>3. Удобная Y>4. Бесплатная
Y>Эта вещь
мне в принципе нравится, но хотелось бы индустриально опробованное и поддерживаемое решение.
E>Не плохо было бы еще и требования к функциональности озвучить.
чем больше тем лучше
а вообще по функциональности можно что-то сравнимое с тем, что по ссылке. а что, так много возможных решений, что нужно по ф-циональности фильтровать? ну так завали меня ссылками!
Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания. Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:
Y>1. Портабельная Y>2. Быстрая Y>3. Удобная Y>4. Бесплатная
мне в принципе нравится, но хотелось бы индустриально опробованное и поддерживаемое решение.
E>>Не плохо было бы еще и требования к функциональности озвучить.
Y>чем больше тем лучше Y>а вообще по функциональности можно что-то сравнимое с тем, что по ссылке. а что, так много возможных решений, что нужно по ф-циональности фильтровать? ну так завали меня ссылками!
Боюсь, что кроме уже предложенной ссылки на работу Константина Книжника, предложить не могу.
Просто у меня уже есть код, который по специальному DDL описанию строит вспомогательный код по созданию C++ объектов по их именам. Если направление рефлекшена будет востребовано, то я задумаюсь о том, чтобы поддержать это направление у себя. Поэтому мне и интересно, что именно от рефлекшена хочется получить:
— получение списка безовых типов?
— возможность инстанцирования и уничтожения объектов по именам типов?
— получение списка атрибутов? Получения указателей на атрибуты или значения атрибутов (как тогда быть с инкапсуляцией)?
— получение указателей на методы или непосредственный вызов указателей?
Что касается решения по ссылке, то мне оно не понравилось из-за обилия ручного кодирования.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Боюсь, что кроме уже предложенной ссылки на работу Константина Книжника, предложить не могу.
E>Просто у меня уже есть код, который по специальному DDL описанию строит вспомогательный код по созданию C++ объектов по их именам. Если направление рефлекшена будет востребовано, то я задумаюсь о том, чтобы поддержать это направление у себя. Поэтому мне и интересно, что именно от рефлекшена хочется получить: E>- получение списка безовых типов? E>- возможность инстанцирования и уничтожения объектов по именам типов? E>- получение списка атрибутов? Получения указателей на атрибуты или значения атрибутов (как тогда быть с инкапсуляцией)? E>- получение указателей на методы или непосредственный вызов указателей?
в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке. а варианты с DDL и специальными парсерами мне очень не нравятся — все должно быть на С++
E>Что касается решения по ссылке, то мне оно не понравилось из-за обилия ручного кодирования.
Сложности, связанные с использованием рефлексии посредством С++ в этой либе меня не сильно пугают, т.к. основная работа с иерархией объектов приложения будет проводится посредством скрипта.
по сути единственное, что меня не устраивает в той библиотеке — необкатанность и неподдерживаемость. ну и еще то, что она Loki использует
Здравствуйте, yxiie, Вы писали:
Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания.
Небольшой список ссылок — http://gzip.rsdn.ru/forum/?mid=937642
мне в принципе нравится, но хотелось бы индустриально опробованное и поддерживаемое решение.
Судя по всему, тоскливо с reflection на C++. Однако, если найдешь что-то интересное, отпиши плз
Здравствуйте, FreshMeat, Вы писали:
FM>Здравствуйте, yxiie, Вы писали:
Y>>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания. FM>Небольшой список ссылок — http://gzip.rsdn.ru/forum/?mid=937642
мне в принципе нравится, но хотелось бы индустриально опробованное и поддерживаемое решение. FM>Судя по всему, тоскливо с reflection на C++. Однако, если найдешь что-то интересное, отпиши плз
Здравствуйте, yxiie, Вы писали:
Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания. Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:
Y>1. Портабельная Y>2. Быстрая Y>3. Удобная Y>4. Бесплатная
Y>Эта вещь
обеспечивает "Full RTTI" ...
даже, какой коментарий стоял напротив class method или data member.
Например, генерация HTML документации полностью реализована на RTTI,
e.g. http://root.cern.ch/root/htmldoc/TRootGuiBuilder.html
Здравствуйте, 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 это же интерпретатор С++, при чем здесь библиотека для рефлексии?
Здравствуйте, yxiie, Вы писали:
Y>Посоветуйте хорошую библиотеку для рефлексии. Сейчас использую свой велосипед, но дальше развивать его нет особого желания. Y>Интересует библиотека как можно более удовлетворяющая требования в таком порядке:
Y>1. Портабельная Y>2. Быстрая Y>3. Удобная Y>4. Бесплатная
Y>Эта вещь
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.
Здравствуйте, 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 .
Здравствуйте, 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, за исключением некоторых нюансов. есть что-то подобное?
Здравствуйте, 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 незавсимое решение
<...>
Y>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец. Y>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.
Боюсь, что если без парсеров и DDL, то объем ручного программирования в конце-концов приведет к невозможности использования такого решения. Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, hth, Вы писали:
hth>>его можно использовать и, как dictionary/(reflection information) generator .
Y>можно подробнее объяснить что и как?
Здравствуйте, eao197, Вы писали:
Y>>да, знаем, есть такое, но не хватало мне ограничить себя GCC, это вообще пипец. Y>>либа нужна чисто на C++ без всяких хитрых хаков, парсеров, DDL, выдирания информации из Debug и.т.д.
E>Боюсь, что если без парсеров и DDL, то объем ручного программирования в конце-концов приведет к невозможности использования такого решения.
ну можно на макросах...
E>Ведь сам оцени, во что выльется сопровождение кода в варианте Batiskaf-а, если потребуется изменить формат метода, который вызывается через reflection?
все равно придется как-то описвать структуру, так пусть лучше это будет несколько макросов на месте, чем еще какие-то левые файлы или тулзы, которые нужно вызывать перед компиляцией.
Здравствуйте, 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 в стандарт языка.
будем внимательно следить за событиями
Здравствуйте, 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>будем внимательно следить за событиями
пока они внесут в стандарт, а потом пока производители компиляторов реализуют...
чувствую придется и дальше велосипед свой дописывать...
Здравствуйте, 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++.
Здравствуйте, 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, что-то генерируется в ран-тайм, где по имени можно оперировать любым объектом. вот такое мне и нужно, только уже готовое и отлаженое, и не надо меня переубеждать
<...>
Y>мне не нужно таких масштабов. мне нужно просто сделать отображение иерархии. Y>у меня сейчас приложение — это динамическая отображенная именованая иерархия, части которой постоянно меняются. что-то загружается из xml, что-то генерируется в ран-тайм, где по имени можно оперировать любым объектом. вот такое мне и нужно, только уже готовое и отлаженое, и не надо меня переубеждать
Ok. Просто стало понятно, что тебе необходимо.
Но я думаю, что тебе не reflection нужен, а интеграция скриптового языка и C++ кода. Может посмотреть, как это сделано в таких языках, как Python, Ruby (там, имхо, попроще, чем в Python), Lua?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ok. Просто стало понятно, что тебе необходимо.
E>Но я думаю, что тебе не reflection нужен, а интеграция скриптового языка и C++ кода. Может посмотреть, как это сделано в таких языках, как Python, Ruby (там, имхо, попроще, чем в Python), Lua?
не совсем. мне не нужно ничего интегрировать, т.к. скрипт-язык сам будет частью системы, в этом то и прикол. если бы мне нужно было просто прикрутить скрипт-язык я бы просто взял boost.python или luabind и не парился. Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>Ok. Просто стало понятно, что тебе необходимо.
E>>Но я думаю, что тебе не reflection нужен, а интеграция скриптового языка и C++ кода. Может посмотреть, как это сделано в таких языках, как Python, Ruby (там, имхо, попроще, чем в Python), Lua?
Y>не совсем. мне не нужно ничего интегрировать, т.к. скрипт-язык сам будет частью системы, в этом то и прикол. если бы мне нужно было просто прикрутить скрипт-язык я бы просто взял boost.python или luabind и не парился. Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.
А ты можешь, если это не секрет, поделится своими идеями на этот счет? А то я, например, не очень понимаю такую вещь. Вот, допустим, в твоем скрипте есть строки:
Я не помнимаю, как для такого кода, с помощью решения Batiskaf-а ты сделаешь вызов метода C++ объекта. Ведь тебе придется в статике, в C++ тексте, написать что-то вроде:
Но, ведь ты заранее не можешь сам описать вызовы всех методов из всех доступных из скрипта классов. Если бы ты мог, то reflection тебе не потребовался бы.
Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А ты можешь, если это не секрет, поделится своими идеями на этот счет? А то я, например, не очень понимаю такую вещь. Вот, допустим, в твоем скрипте есть строки:
E>
E>Я не помнимаю, как для такого кода, с помощью решения Batiskaf-а ты сделаешь вызов метода C++ объекта. Ведь тебе придется в статике, в C++ тексте, написать что-то вроде:
...
E>Но, ведь ты заранее не можешь сам описать вызовы всех методов из всех доступных из скрипта классов. Если бы ты мог, то reflection тебе не потребовался бы.
E>Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?
нет никаких длл. забыл, что у меня первым пунктом стоит портабельность?
как я вызову? просто нужно будет расширить этот код так, чтобы при регистрации метода он еще и добавлял информацию о параметрах метода, таким образом
у нас в ран-тайм будет полная сигнатура метода класса, по которой скрипту не составит труда найти нужный метод.
Здравствуйте, yxiie, Вы писали: Y>Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются.
По моему тут некоторое противоречие: или скорость выполнения и статический контроль типов, или скорость и прозрачность разработки в скриптовом языке.
Вез жертв тут не обойтись.
Когда я сталкивался с похожей задачей, была реализована отдельная "высокоуровнивая" иерархия специально для скриптования.
Мы её расширяли/изменяли по мере надобности.
Если вдруг обнаруживали часто встречающуюся или недостающую задачу.
Тут ещё играет роль тот фактор, что скрипты часто пишут конечные пользователи, у которых достаточно мало опыта как в написании программ, так и в отладке. А ядро системы всё-таки более квалифицированные програмеры.
Соответственно нужен более "надёжный" и "защищённый" от дурака язык. Понятно, что если одни и те же классы мы попытаемся использовать и там и там, получим либо утяжеление в C++ либо напряги в скрипте.
А как наиболее прозрачное решение можно посоветовать либо всё делать на COM/CORBA, либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.
Здравствуйте, Tonal-, Вы писали:
T>Здравствуйте, yxiie, Вы писали: Y>>Тут нужно иметь общую иерархию, с которой можно было сравнительно одинаково удобно работать как на С++ (там где нужна скорость) так и на скрипт-языке (там где скорость не критична). плюс всякие бонусы типа сериализации приветствуются. T>По моему тут некоторое противоречие: или скорость выполнения и статический контроль типов, или скорость и прозрачность разработки в скриптовом языке. T>Вез жертв тут не обойтись.
почему же противоречие? когда работаем на С++ имеем скорость и контроль. когда на скриптовом языке — имеем удобность и прозрачность.
T>Когда я сталкивался с похожей задачей, была реализована отдельная "высокоуровнивая" иерархия специально для скриптования. T>Мы её расширяли/изменяли по мере надобности. T>Если вдруг обнаруживали часто встречающуюся или недостающую задачу.
у меня щас тоже так, и где я говорил, что я против такого?
T>Тут ещё играет роль тот фактор, что скрипты часто пишут конечные пользователи, у которых достаточно мало опыта как в написании программ, так и в отладке. А ядро системы всё-таки более квалифицированные програмеры.
какой еще фактор? это основная причина, по которой я все это дело затеял.
T>Соответственно нужен более "надёжный" и "защищённый" от дурака язык. Понятно, что если одни и те же классы мы попытаемся использовать и там и там, получим либо утяжеление в C++ либо напряги в скрипте.
скрипт язык будет клоном JavaScript.
T>А как наиболее прозрачное решение можно посоветовать либо всё делать на COM/CORBA,
не портабельно, а это условие номер 1.
T>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.
Здравствуйте, hth, Вы писали:
T>>>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.
Y>>слишком сложный скрипт-язык.
hth>C++ — сложный, согласен, hth>но C — очень простой,
простой для тебя, для меня, для программиста.
а скрипты предполагается будут писать непрограммисты.
hth>какой еще проще?
я уже сказал — JavaScript. практика использования Macromedia Flash показывает, что дизайнеры могут вполне сносно его использовать (напомню ActionScript из Flash — по сути обрезанный JavaScript)
hth>Если нужна простата — пользуй C!
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, hth, Вы писали:
T>>>>либо взять интерпретатор Cint из Root-а или Виртуальную машину для С++.
Y>>>слишком сложный скрипт-язык.
hth>>C++ — сложный, согласен, hth>>но C — очень простой,
Y>простой для тебя, для меня, для программиста. Y>а скрипты предполагается будут писать непрограммисты.
hth>>какой еще проще?
Y>я уже сказал — JavaScript. практика использования Macromedia Flash показывает, что дизайнеры могут вполне сносно его использовать (напомню ActionScript из Flash — по сути обрезанный JavaScript)
hth>>Если нужна простата — пользуй C!
Y>нет уж спасибо
потушим так любимый ламерами и льюзерами пионерский костер!
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>А ты можешь, если это не секрет, поделится своими идеями на этот счет? А то я, например, не очень понимаю такую вещь. Вот, допустим, в твоем скрипте есть строки:
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++ коде не было конструкции:
1. Реализовать возможность вызова метода вручную запихивая параметры в стек и используюя ассемблерную инструкцию call. Но тогда о переносимости можно забыть.
2. Самому делать proxy для вызова методов объектов, например, в виде:
ИМХО, создание таких proxy -- это не есть механизм reflection.
Более того, такие задачи уже были решены в языках типа Ruby, Python, Lua, ... Есть даже проект Swig, который, насколько я его понимаю, значительно упрощает интеграцию скриптовых языков с языками типа C/C++, C#, Java. Может тебе в ту сторону посмотреть?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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>ИМХО, здесь у тебя два варианта:
E>1. Реализовать возможность вызова метода вручную запихивая параметры в стек и используюя ассемблерную инструкцию call. Но тогда о переносимости можно забыть.
E>2. Самому делать proxy для вызова методов объектов, например, в виде: E>
да, скорее всего второй вариант, только зачем самому делать прокси? у байндера к методу будет ф-ция, которая будет
принимать параметры скрипта и на основе их формировать вызов С++ метода.
E>ИМХО, создание таких proxy -- это не есть механизм reflection.
не понял, объясни, что ты хочешь сказать.
E>Более того, такие задачи уже были решены в языках типа Ruby, Python, Lua, ...
такие, да, но не все. по сути либы типа boost.python делают только байнд. мне же скорее нужно что-то среднее между байндом и полноценной рефлексией.
E>Есть даже проект Swig, который, насколько я его понимаю, значительно упрощает интеграцию скриптовых языков с языками типа C/C++, C#, Java. Может тебе в ту сторону посмотреть?
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>>>Или ты по скрипту будешь генерировать C++ код, затем компилировать его в dll, подгружать dll и вызывать оттуда сгенерированную заглушку?
Y>>>нет никаких длл. забыл, что у меня первым пунктом стоит портабельность?
E>>Нет, не забыл. Но перечисли, пожалуйста, платформы, на которых предполагается использовать твою систему, и на которой не будет DLL
Y>любая игровая консоль...
Ну не любая
На XBox, например, Windows стоит. Там DLL-ки точно есть
А под какими OS, например, Sony PS работает, я не знаю.
<...>
E>>2. Самому делать proxy для вызова методов объектов, например, в виде: E>>
Y>да, скорее всего второй вариант, только зачем самому делать прокси? у байндера к методу будет ф-ция, которая будет Y>принимать параметры скрипта и на основе их формировать вызов С++ метода.
Но как делать вызов? Мне просто интересно код такого байндера увидеть.
E>>ИМХО, создание таких proxy -- это не есть механизм reflection.
Y>не понял, объясни, что ты хочешь сказать.
Ok. Но мне нужно некоторое время, чтобы восстановить в памяти информацию по reflection в Java. Тогда попробую объяснить.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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 там же все открыто, или я не понял, что именно ты хочешь увидеть?
Здравствуйте, 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, я же уже спрашивал раньше. Мне интересно, как появится такой код:
Здравствуйте, 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>Его что, ручками нужно написать? E>Для каждого метода, который можно вызывать из скрипта?
а зачем такой код? такой код будет использоваться только в С++, для скрипта будет скорее что-то типа
BindedMethod->Invoke(obj, params);
E>Кстати, из скрипта ведь можно будет не все C++ объекты инстанциировать? А только специально для этого предназначенные.
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++.
E>>>Его что, ручками нужно написать? E>>>Для каждого метода, который можно вызывать из скрипта?
Y>>а зачем такой код? такой код будет использоваться только в С++, для скрипта будет скорее что-то типа
Y>>BindedMethod->Invoke(obj, params);
E>Так вот и я об этом же. Что из скрипта будет вызываться некий Invoke, а уже в Invoke будет код, который приведен выше. Так?
зачем? в байнд-объекте мы уже имеем адрес метода и информацию о параметрах. единственное, что нужно — обработать и преобразовать переданные
скриптом параметры в подходящие для этого метода и сделать вызов.
E>>>Кстати, из скрипта ведь можно будет не все C++ объекты инстанциировать? А только специально для этого предназначенные.
Y>>те, которые зарегистрированы, да.
E>Так вот, если объекты, которые ты делаешь доступными для скрипта и методы этих объектов заранее определены, то зачем огород с reflection?
E>Почему просто не сделать BindedMethod->Invoke оберткой сразу над конкретным C++ классом/интерфейсом? А уже нужные тебе C++ классы/интерфейсы инстанциировать посредством фабрики?
потому, что если мы обойдемся только байндом, то из скрипта мы сможем оперировать объектами С++, а из С++ оперировать объектами скрипта — нет.
Здравствуйте, 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++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, yxiie, Вы писали:
E>>>Так вот и я об этом же. Что из скрипта будет вызываться некий Invoke, а уже в Invoke будет код, который приведен выше. Так?
Y>>зачем? в байнд-объекте мы уже имеем адрес метода и информацию о параметрах. единственное, что нужно — обработать и преобразовать переданные Y>>скриптом параметры в подходящие для этого метода и сделать вызов.
E>Но КАК? (Торможу я что-то). Приведи, пожалуйста код по организации вызова метода, сигнатура которого заранее была неизвестна.
почему же неизвестна? посмотри в исходниках Batiskaf-a как у него сделана регистрация метода — BindMethod. если все-равно будет неясно, тогда попробую объяснить.
E>>>Так вот, если объекты, которые ты делаешь доступными для скрипта и методы этих объектов заранее определены, то зачем огород с reflection?
E>>>Почему просто не сделать BindedMethod->Invoke оберткой сразу над конкретным C++ классом/интерфейсом? А уже нужные тебе C++ классы/интерфейсы инстанциировать посредством фабрики?
Y>>потому, что если мы обойдемся только байндом, то из скрипта мы сможем оперировать объектами С++, а из С++ оперировать объектами скрипта — нет.
E>Ну это ты зря. Это уж как напишешь.
ну и какая тогда будет разница между такими наворотами продвинутого байнда и рефлексией?
Здравствуйте, 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++.
Здравствуйте, eao197, Вы писали:
E>Объясняй сразу. Ведь мне не интересны внутренности регистрации метода через BindMethod. Мне интересно, как ты будешь через reflection вызывать метод, сигнатуру которого ты до этого не знал. Ведь в примере, который привел Batiskaf показано, что сигнатура должна быть известна (привел бы оттуда фрагмент с GetMethod, но у того метода простая сигнатура):
...
лучше бы ты посмотрел. там у него BindMethod — это переопрделенное имя:
таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать
параметры из скрипта и на основе их делать вызов.
Здравствуйте, eao197, Вы писали:
E>>>ИМХО, создание таких proxy -- это не есть механизм reflection.
Y>>не понял, объясни, что ты хочешь сказать.
E>Ok. Но мне нужно некоторое время, чтобы восстановить в памяти информацию по reflection в Java. Тогда попробую объяснить.
Просто, как я понял твою задачу, тебе нужна только одна возможность из reflection -- вызов метода. Все остальное ты проигнорируешь.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Просто, как я понял твою задачу, тебе нужна только одна возможность из reflection -- вызов метода. Все остальное ты проигнорируешь.
опиши мне все возможности reflection и я скажу, какие я проигнорирую, какие нет.
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>Объясняй сразу. Ведь мне не интересны внутренности регистрации метода через BindMethod. Мне интересно, как ты будешь через reflection вызывать метод, сигнатуру которого ты до этого не знал. Ведь в примере, который привел Batiskaf показано, что сигнатура должна быть известна (привел бы оттуда фрагмент с GetMethod, но у того метода простая сигнатура):
Y>...
Y>лучше бы ты посмотрел. там у него BindMethod — это переопрделенное имя:
Y>
Да понимаю я это, ты мне вот что покажи:
Y>таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать Y>параметры из скрипта и на основе их делать вызов.
Как???
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Да понимаю я это, ты мне вот что покажи:
Y>>таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать Y>>параметры из скрипта и на основе их делать вызов.
E>Как???
Здравствуйте, sch, Вы писали:
E>>Так вот и я о том же! sch>Интересно, а вот так получится? Только придется варианты использовать, а это уже медленно...
<...>
Здравствуйте, sch, Вы писали:
SS>>Получится. А чем variant медленно? sch>Это мой маленький пунктик, если я где вижу лишний malloc() то меня тут же начинает передергивать
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>Да понимаю я это, ты мне вот что покажи:
Y>>>таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать Y>>>параметры из скрипта и на основе их делать вызов.
E>>Как???
Y>
...
Y>
Y>конечно это все быстрый набросок, но надеюсь идея ясна.
Да, что-то такое я предполагал с самого начала.
ИМХО, в системе интеграции Ruby с C гораздо проще все сделано. "Чего только русские не придумают, чтобы нормальные дороги не строить"
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>Просто, как я понял твою задачу, тебе нужна только одна возможность из reflection -- вызов метода. Все остальное ты проигнорируешь.
Y>опиши мне все возможности reflection и я скажу, какие я проигнорирую, какие нет.
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++.
Здравствуйте, 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++ этого достичь портабильным способом?
я с жавой близко не знаком, так что ничего сказать не могу.
имхо вы хотите того чего не нужно никому и никогда.
зачем тут нужна рефлексия?
чтобы скрипт вызвал нужный метод достаточно зарегистрировать в виртуальной машине как его вызывать.
Самый простой способ — автоматическая регистрация : те
*при компиляции с++ создаются заглушки, которые преобразовывают аргументы пришедшие из скрипта в нормальный вызов с++ метода
*при компиляции с++ создается код который регистрирует заглушки в скрипте при старте vm
после этого юзер может скриптить сколько угодно.
Главная проблема — интерфейсы менять уже будет нельзя или скрипты придется выкинуть и писать наново.
wbr
зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, yxiie:
SD>имхо вы хотите того чего не нужно никому и никогда. SD>зачем тут нужна рефлексия?
эээ... не понял
SD>чтобы скрипт вызвал нужный метод достаточно зарегистрировать в виртуальной машине как его вызывать. SD>Самый простой способ — автоматическая регистрация : те SD>*при компиляции с++ создаются заглушки, которые преобразовывают аргументы пришедшие из скрипта в нормальный вызов с++ метода SD>*при компиляции с++ создается код который регистрирует заглушки в скрипте при старте vm
может быть, а чтобы скрипт создал экземпляр native C++ класса?
SD>после этого юзер может скриптить сколько угодно. SD>Главная проблема — интерфейсы менять уже будет нельзя или скрипты придется выкинуть и писать наново.
SD>wbr
SD>зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор
честно говоря я абсолютно не понял, что вы хотели сказать
это замечание? возражение? уточнение?
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, SleepyDrago, Вы писали:
SD>>Здравствуйте, yxiie:
SD>>имхо вы хотите того чего не нужно никому и никогда. SD>>зачем тут нужна рефлексия?
Y>эээ... не понял
SD>>чтобы скрипт вызвал нужный метод достаточно зарегистрировать в виртуальной машине как его вызывать. SD>>Самый простой способ — автоматическая регистрация : те SD>>*при компиляции с++ создаются заглушки, которые преобразовывают аргументы пришедшие из скрипта в нормальный вызов с++ метода SD>>*при компиляции с++ создается код который регистрирует заглушки в скрипте при старте vm
Y>может быть, а чтобы скрипт создал экземпляр native C++ класса?
Запросто — зарегать фабрику этого класса
+ зарегать сам класс //он же статически скомпилен уже
SD>>зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор Y>честно говоря я абсолютно не понял, что вы хотели сказать Y>это замечание? возражение? уточнение?
вопрос к афтору — "зачем и для чего нужна такая система".
если я правильно понял то и мне такая нужна — только руки никак не доходили.
Здравствуйте, SleepyDrago, Вы писали:
SD>Запросто — зарегать фабрику этого класса SD>+ зарегать сам класс //он же статически скомпилен уже
ну дак по большому счету script-binding это и есть большая умная фабрика
му уже это обсуждали где-то в теме, нет желания по второму кругу воду в ступе.
SD>>>зы поделитесь идеями vm а то уже интересно ради чего весь сыр-бор Y>>честно говоря я абсолютно не понял, что вы хотели сказать Y>>это замечание? возражение? уточнение?
SD>вопрос к афтору — "зачем и для чего нужна такая система". SD>если я правильно понял то и мне такая нужна — только руки никак не доходили.
я ведь уже упоминал — для использования в разработке игр, если сделать правильно — позволит серьезно упростить процес разработки и немало сэкономить за счет того, что часть игры смогут писать люди без глубоких знаний C++.
Здравствуйте, yxiie, Вы писали:
Y>ну дак по большому счету script-binding это и есть большая умная фабрика Y>му уже это обсуждали где-то в теме, нет желания по второму кругу воду в ступе.
Дык ИМХО рефлексия тут не причем. Есть код назовем его "А" и нужно получить по нему код
врапперов назовем его "Б". причем процесс получения это часть процесса сборки.
Тут уже много раз писали переписали на эту тему (вон недавно Кодт хотел через DIA для сериализации)
ну и воз и ныне там.
Если у Вас есть идея как это сделать надежно — поделитесь.
Если нет и только спрашиваете — тогда ответ никак. Своими хаками через парсеры кода, через DIA или даже ручками — одинаково ненадежно и неудобно ИМХО.
Личный опыт — каждое изменение в интерфейсе с++ -> скрипт будет давать вам тонны нерабочих скриптов
при том что отладчика скриптов как правило нет или он с трудом понимает ваши с++ расширения.
Отсюда глубокое имхо менять эти интерфейсы так редко и так внимательно что РУКАМИ это САМЫЙ надежный способ. Пример кода заглушки
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, yxiie, Вы писали:
Y>>ну дак по большому счету script-binding это и есть большая умная фабрика Y>>му уже это обсуждали где-то в теме, нет желания по второму кругу воду в ступе.
SD>Дык ИМХО рефлексия тут не причем. Есть код назовем его "А" и нужно получить по нему код SD>врапперов назовем его "Б". причем процесс получения это часть процесса сборки. SD>Тут уже много раз писали переписали на эту тему (вон недавно Кодт хотел через DIA для сериализации) SD>ну и воз и ныне там. SD>Если у Вас есть идея как это сделать надежно — поделитесь.
что сделать???
вы что-то надумали себе и хотите, чтобы я о чем-то поделился. внимательно перечитайте всю эту тему. если что-то *конкретное* не понятно — спрашивайте, а то тут какие-то врапперы пошли, какой-то процесс получения...
SD>Если нет и только спрашиваете — тогда ответ никак. Своими хаками через парсеры кода, через DIA или даже ручками — одинаково ненадежно и неудобно ИМХО.
какие парсеры, какой DIA — у меня первым пунктом стоит портабельность, а парсеры — это не мой стиль.
я вроде уже еао197 объяснил — он все понял, что я хочу делать. Будьте добры, перечитайте и вы тему, чтобы задавать вопросы которые я пойму и смогу ответить.
SD>Личный опыт — каждое изменение в интерфейсе с++ -> скрипт будет давать вам тонны нерабочих скриптов SD>при том что отладчика скриптов как правило нет или он с трудом понимает ваши с++ расширения. 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
зы поменьше эмоций.
Мне самому нужно нечто подобное так что "удачи!".
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, yxiie, Вы писали:
Y>>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке. а варианты с DDL и специальными парсерами мне очень не нравятся — все должно быть на С++
А>Доктор ! где здесь рефлексия ? А>*Есть статически скомпиленная иерархия классов С++ А>*Есть динамический скрипт который цепляется к ней и расширяет эту иерархию.
а динамическая именованая иерархия, которая дублирует статическую иерархию на С++ это что?
приведи мне твое определение рефлексии...
А>wbr А>зы поменьше эмоций.
если содержание сообщений не будет вилять туда-сюда, от DIA до LUA, я не буду огорчаться по поводу невозможности аргументированно ответить
Здравствуйте, yxiie, Вы писали:
SD>>Если нет и только спрашиваете — тогда ответ никак. Своими хаками через парсеры кода, через DIA или даже ручками — одинаково ненадежно и неудобно ИМХО.
Y>какие парсеры, какой DIA — у меня первым пунктом стоит портабельность, а парсеры — это не мой стиль. Y>я вроде уже еао197 объяснил — он все понял, что я хочу делать. Будьте добры, перечитайте и вы тему, чтобы задавать вопросы которые я пойму и смогу ответить.
Что бы прояснить: я понял (как мне кажется), что хочет yxiie. Но, во-первых, я не думаю, что так нужно делать (я согласен с предложениями SleepyDrago). И, во-вторых, я не уверен, что из этого что-либо хорошее получится. Но, т.к. это только мое имхо, то я решил свернуть тему.
Все равно желаю, тебе, yxiie, удачи! Дело это сложное, но интересное.
Если что-то получится и можно будет озвучить результаты -- поделись впечатлениями, ладно?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, <Аноним>, Вы писали:
А>>Здравствуйте, yxiie, Вы писали:
извиняюсь — глюкнул браузер те аноним это я
Y>>>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке. а варианты с DDL и специальными парсерами мне очень не нравятся — все должно быть на С++
А>>Доктор ! где здесь рефлексия ? А>>*Есть статически скомпиленная иерархия классов С++ А>>*Есть динамический скрипт который цепляется к ней и расширяет эту иерархию.
Y>а динамическая именованая иерархия, которая дублирует статическую иерархию на С++ это что? Y>приведи мне твое определение рефлексии...
Вместо этого я предлагаю Вам подумать над тем:
*** в какой среде будет исполняться
Y>а динамическая именованая иерархия, которая дублирует статическую иерархию на С++
?
ответ на этот вопрос должен сильно прояснить природу исходного вопроса
Y>>>в идеале — все. нужно, чтобы создавалась динамическая объектная модель приложения, с которой можно будет работать как на С++ так и на встроенном скриптовом языке.
имхо все остальные вопросы по рефлексии и генерации кода _после_ ответа на ***
должны просто отпасть
wbr
Re: Reflection for C++: если уж это для разработки игр
Здравствуйте, 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++: если уж это для разработки игр
Хотелось бы вернуть обсуждение в более конструктивное русло.
Итак, у нас есть структуры, описывающие методы и поля. Чтобы дать возможность обратиться к этим полям и методам, мы должны сделать некий map, один на каждый класс, в котором мы будем регистрировать метаданные, после чего обращаться к ним через map. Но вот меня интересует следующий вопрос: ведь метаданные статичны, однако мы будем создавать их как минимум один раз для каждого класса. Хотелось бы получить статичный метод вызова, который бы решал этот вопрос более эффективынм, быстрым и надежным путем.
Здравствуйте, sch, Вы писали:
sch>Хотелось бы вернуть обсуждение в более конструктивное русло.
Ok. Давайте пофантазируем о reflection в С++ вообще, безотносительно к прикладной задаче yxiie.
sch>Итак, у нас есть структуры, описывающие методы и поля. Чтобы дать возможность обратиться к этим полям и методам, мы должны сделать некий map, один на каждый класс, в котором мы будем регистрировать метаданные, после чего обращаться к ним через map. Но вот меня интересует следующий вопрос: ведь метаданные статичны, однако мы будем создавать их как минимум один раз для каждого класса. Хотелось бы получить статичный метод вызова, который бы решал этот вопрос более эффективынм, быстрым и надежным путем.
Все, что будет сказано ниже, является моим субъективным мнением, которое я никому не навязываю. Более того, мне бы хотелось услышать о более простых способах организации reflection в C++.
Очень хорошо по этому поводу высказался Константин Книжник. Лично я к этом могу добавить только следующее: т.к. reflection не поддерживается на уровне языка (как в Java, например) то остается всего два пути для получения портабельного решения. Либо делать ручное описание классов, их атрибутов и методов с помощью макросов или шаблонов. Либо использовать внешние инструменты, которые генерят С++ код с метаданными по каким-то описаниям. Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.
В варианте с внешними инструментами возможны два подхода:
1. Описание схемы данных делается на специальном Data Definition Language, а не на C++. Затем это описание пропускается через специализированный транслятор, который и строит код с метаданными. Простой вариант с точки зрения реализации такого транслятора, особенно, если синтаксис DDL прост. Может быть слишком трудоемким в использовании, если одни и те же данные нужно будет описывать и на C++ и на DDL. Возможный выход -- генерация по DDL описанию не только кода с метаданными, но и самих описаний C++ типов.
Лично я выбрал именно этот способ для своего проекта по сериализации и долговременному хранению данных, т.к. его можно было реализовать своими силами.
2. Описание схемы данных поднимается из обычного C++ описания. Проблема состоит в создании парсера C++, который бы мог это делать. Она может быть решена, например, использованием таких средств как gcc-xml, CInt. Так же adontz нашел какую-то возможность извлекать эту информацию из C++ кода для Visual Studio (Проект сериализации — 2 [просьба высказаться]
Я также рассматривал еще вариант использования инструментов типа doxygen и ccdoc: в комментариях к классам, методам, атрибутам выставляешь специальные теги, которые игнорируются обычным doxygen (ccdoc), но извлекаются их модифицированными версиями. Затем строится код с метаданными. Вот, например, как это могло выглядеть:
/*!
\brief Информация о пользователе.
\reflected
Хранит login, имя, описание пользователя, а также ...
*/class user_info_t
{
private :
/*!
\brief Логин пользователя.
\reflected
*/
std::string m_login;
...
public :
/*!
\brief Конструктор по-умолчанию.
\reflected
*/
user_info_t();
/*!
\brief Устанавливает имя пользователя и пароль.
\reflected
*/
user_info_t(
const std::string & login,
const std::string & password );
...
};
Мне больше симпатичны способы с отдельным DDL или последний способ с doxygen (ccdoc) /фактически, это очень похоже на DDL, который растворен в C++/. Такие способы позволяют делать дополнительные описания, которые нельзя сделать в C++, но которые могут быть полезны, например, при сериализации.
Вообще, имхо, механизм reflection в Java крут и полезен благодоря одной важной фишке: возможности вызова метода не зная заранее его сигнатуры и передавая все параметры ему в виде Object[]. В C++ я не знаю портабельного способа для выполнения этого. Отсюда, лично для меня, следуют следующие выводы:
— если в C++ механизм reflection нужен для инстанцирования объектов по строковому имени их класса, то для этого подходят фабрики;
— если в C++ механизм reflection нужен для сериализации, то готовых решений для сериализации уже как собак не резаных развелось. Более того, для сериализации может быть черезвычайно важна информация, которую нельзя представить в синтаксисе C++. Например, является ли атрибут необязательным (т.е. должен ли он сериализоваться, если содержит значение по-умолчанию). А так же в сериализации нужно решать вопросы версионности сериализованных образов, для которых так же может потребоваться дополнительная информация;
— если в C++ механизм reflection нужен для вызова произвольных методов с произвольными сигнатурами, то, имхо, портабельно это сделать невозможно. Все равно придется органичиваться какими-то методами с известными сигнатурами (тогда можно использовать интерфейсы и фабрики) или придется писать обертки для того, чтобы сделать нормальный вызов, выбрав все параметры из какого-нибудь std::vector< script_expression_t * >. Но и эти задачи уже были неоднократно решены применительно к скриптовым языкам.
Поэтому для меня, reflection в C++ -- это баловство, попытка перенести в язык концепцию, взятую из принципиально другого языка. По крайней мере сейчас, пока в C++ нет стандартной поддержки reflection.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
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++: если уж это для разработки игр
Здравствуйте, eao197, Вы писали:
E>Yxiie, если ты планируешь создать скриптовый язык для программирования игр, то может быть имеет смысл посмотреть сначала в сторону языка Pike.
спасибо, посмотрю.
E>Он очень похож на C++, но интерпритируется. Изначально он как раз и создавался для разработки игр.
нет, скрипт язык будет однозначно JavaScript или клон его. как я уже писал, практика показывает, что он достаточно простой для того, чтобы даже дизайнеры могли его использовать. кроме того человеку можно сказать просто: купи книгу по JavaScript а не объяснять особенности доморощенного синтаксиса или писать доку по своему языку (бррр...)
E>А его разработчики уверяют, что у него очень высокая скорость работы для своего класса языков.
ну скорость в принципе не фатальна, т.к. на скрипт-языке не будут решаться time-critical задачи.
E>Если ты занимаешься разработкой своей задачи не для собственного интереса, то может имеет смысл глянуть на уже готовые решения в области скриптовых языков?
смотрел
E> Ведь создать свой скриптовый язык, более мощный, чем тот же Pike, ох как не просто.
еще не смотрел Pike, но скажу что реализовать JavaScript не так уж и трудно. клон последнего я сделал, когда только начинал изучать С++ (собственно в процессе написания подобного интерпретатора я и изучал С++ )
E>Хотя, если ты это делаешь в качестве хобби, то это совсем другое дело
Здравствуйте, eao197, Вы писали:
E>Что бы прояснить: я понял (как мне кажется), что хочет yxiie. Но, во-первых, я не думаю, что так нужно делать (я согласен с предложениями SleepyDrago). И, во-вторых, я не уверен, что из этого что-либо хорошее получится. Но, т.к. это только мое имхо, то я решил свернуть тему.
E>Все равно желаю, тебе, yxiie, удачи! Дело это сложное, но интересное.
я не говорил, что будет просто
кстати есть реальные примеры того, что я хочу:
игровой движок Nebula интегрирован с Tcl/Tk так как я хочу интегрировать с JavaScript...
E>Если что-то получится и можно будет озвучить результаты -- поделись впечатлениями, ладно?
не думаю, что скоро это будет — я пока присматриваюсь, но если будет что — озвучу.
... << RSDN@Home 1.1.3 stable >>
Re[3]: Reflection for C++: если уж это для разработки игр
<...>
Y>нет, скрипт язык будет однозначно JavaScript или клон его. как я уже писал, практика показывает, что он достаточно простой для того, чтобы даже дизайнеры могли его использовать. кроме того человеку можно сказать просто: купи книгу по JavaScript а не объяснять особенности доморощенного синтаксиса или писать доку по своему языку (бррр...)
А вот это (DMDScript) ты рассматривал?
E>>А его разработчики уверяют, что у него очень высокая скорость работы для своего класса языков.
Y>ну скорость в принципе не фатальна, т.к. на скрипт-языке не будут решаться time-critical задачи.
Думаю, что это не надолго.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>>Лично я выбрал именно этот способ для своего проекта по сериализации и долговременному хранению данных, т.к. его можно было реализовать своими силами.
Y>интересно, чем этот вариант отличается от ручного задания формата класса (регистрация полей и методов) в плане Y>
Y>Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.
Y>?
Видимо, eao197 имел ввиду, что при каждом изменении сигнатуры метода придется переписывать и определение. Однако я такую проблему решил следующим образом:
// естественно в качестве варианта можно и нужно использовать variant;)class A: public ReflectedClass<int> {
public:
int fn(int p1) {
printf("A::fn(%d)\n",p1);
return 1;
}
int fnx(int p1,int p2) {
printf("A::fnx(%d,%d)\n",p1,p2);
return 1;
}
A() {
RegisterMethod("fn",declaration(this,fn,int()));
RegisterMethod("fnx",declaration(this,fnx,int()));
}
};
Здравствуйте, sch, Вы писали:
E>>>Лично я выбрал именно этот способ для своего проекта по сериализации и долговременному хранению данных, т.к. его можно было реализовать своими силами.
Y>>интересно, чем этот вариант отличается от ручного задания формата класса (регистрация полей и методов) в плане Y>>
Y>>Вариант с ручным описанием я считаю слишком трудоемким, череватым ошибками, и сложным в сопровождении при изменении схемы данных.
Y>>?
sch>Видимо, eao197 имел ввиду, что при каждом изменении сигнатуры метода придется переписывать и определение. Однако я такую проблему решил следующим образом:
...
да нет, тут наверное что-то другое, т.к. такое решение есть и у Batiskaf-a а мы это уже давно обсудили.
Здравствуйте, 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++.
Здравствуйте, yxiie, Вы писали:
Y>Здравствуйте, eao197, Вы писали:
E>>Да понимаю я это, ты мне вот что покажи:
Y>>>таким образом мы знаем сигнатуру и можем сгенерировать соответствующий объект, который будет принимать Y>>>параметры из скрипта и на основе их делать вызов.
E>>Как???
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.
Здравствуйте, Batiskaf, Вы писали:
Y>>конечно это все быстрый набросок, но надеюсь идея ясна. B>Вечер добрый. Не думал что такими экзотическими для С++ программиста штуками (рефлексия) кто то еще заинтересуется. В свое время я думал соорудить динамическую версию метод-прокси, в дополнение к той статической версии, которая для программистов С++ гораздо более удобна. Но времени на все не хватило, успел только VariantProperty (см. Property.h file). Если есть желание и время можете добавить по аналогии с VariantProperty.
Добрый вечер. Да, интересуюсь очень, код ваш очень хороший, на многие идеи меня натолкнул, вот только боюсь использовать его буду только как источник вдохновения — проще самому написать под конкретные задачи.
B>Хотя так не долго и до джавы со смолтоком дожиться, от лукавого это все
возможно, но на целевых платформах — С++ это потолок, и то с ограниченными возможностями (часто нету exceptions и rtti). так что если жаву придется изобретать — никуда не денешься, но я думаю до этого не дойдет если подойти без фанатизма, то все должно получится.
Здравствуйте, 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.
Здравствуйте, Batiskaf, Вы писали:
Y>>Добрый вечер. Да, интересуюсь очень, код ваш очень хороший, на многие идеи меня натолкнул, вот только боюсь использовать его буду только как источник вдохновения — проще самому написать под конкретные задачи.
B>А что мешает использовать не только для вдохновения? С коментариями у меня на самом деле не сложилось, но если будут заинтересованные то это можно устроить, открыт к обсуждению любых предложений и идей, правда времени маловато, если кто то готов потратить свои драгоценные моменты жизни на эту идею, так за это слава и почет ждет этого великого програмиста.
мешает то, что код не поддерживается. вы это написали когда-то и забыли, а я если и буду использовать это — то использовать в коммерческом проекте, придется тесно работать с библиотекой и лбом сталкиватся со всеми проблемами, а т.к. либа не поддерживается — искать и фиксить все баги придется самому. поэтому проще написать свое точно зная что где происходит. плюс мне придется расширять ее — делать динамический вызов методов, также придется переводить на boost и.т.д.