Ааа подскажите, пожалуйста, по потенциальным полям — вот стоит в дальнем углу противник.
Он должен генерировать притягивающее потенциальное поле. Волнующие вопросы:
1) Как подбирать значения эмиттера? Ставить какие-нибудь 10000, чтоб затухая на 1 по клетке волна гарантировано дошла до края карты? Возможно, просто что-то не так понимаю.
2) Надо держать сразу несколько потенциальных полей и обновлять их все параллельно? Для одних юнитов может строиться по одному закону, для других (дальнобойных, союзных, лечащих, ...) по-другому.
Спасибо за добавление. Не упомянул, т.к. reflection в QT не основная задача и тянет с собой много чего другого.
Опять же, решения с дополнительным toolchain не рассматривались.
Кстати, автор библиотеки uMOF как раз таки, похоже, и вдохновлялся QT.
Его решение тоже хранит мета-информацию в статической памяти, но задается она вручную.
Конечно, не спорю. Но число 17 слегка угнетает, особенно учитывая будущие задержки в реализации поддержки этого всего компиляторами.
А хочется уже здесь и сейчас, уж слишком много интересных плюшек это дает.
Понимаю, что краткая. Эта статья — пересечение огромного личного интереса с невероятно скудной информацией на эту тему.
Собирал в основном для себя, но потом решил поделиться, хоть немного систематизировав.
Есть еще boost.mirror и boost.reflex.
boost.mirror выглядит просто гигантским монстром, разбит на несколько под-мета-библиотек и т.д. (хотя, может, и ошибаюсь).
boost.reflex — маловато информации, версия 0.1, не совсем понятно что за продукт и какая его судьба хотя бы в ближайшем будущем.
Есть benchmark на сайте библиотеки RTTR — www.axelmenzel.de/articles/rtti
Сама библиотека показала здесь не лучшие результаты в производительности, но и их достаточно, чтоб обогнать dynamic_cast.
Хотя, может, у автора специально проводились какие-то оптимизации под это.
А вообще да, dynamic_cast это явно не важнейшая задача для reflection, добавил в список больше для примера.
Он должен генерировать притягивающее потенциальное поле. Волнующие вопросы:
1) Как подбирать значения эмиттера? Ставить какие-нибудь 10000, чтоб затухая на 1 по клетке волна гарантировано дошла до края карты? Возможно, просто что-то не так понимаю.
2) Надо держать сразу несколько потенциальных полей и обновлять их все параллельно? Для одних юнитов может строиться по одному закону, для других (дальнобойных, союзных, лечащих, ...) по-другому.
Заранее огромное спасибо, тема очень интересная.
Опять же, решения с дополнительным toolchain не рассматривались.
Кстати, автор библиотеки uMOF как раз таки, похоже, и вдохновлялся QT.
Его решение тоже хранит мета-информацию в статической памяти, но задается она вручную.
А хочется уже здесь и сейчас, уж слишком много интересных плюшек это дает.
Собирал в основном для себя, но потом решил поделиться, хоть немного систематизировав.
Есть еще boost.mirror и boost.reflex.
boost.mirror выглядит просто гигантским монстром, разбит на несколько под-мета-библиотек и т.д. (хотя, может, и ошибаюсь).
boost.reflex — маловато информации, версия 0.1, не совсем понятно что за продукт и какая его судьба хотя бы в ближайшем будущем.
Сама библиотека показала здесь не лучшие результаты в производительности, но и их достаточно, чтоб обогнать dynamic_cast.
Хотя, может, у автора специально проводились какие-то оптимизации под это.
А вообще да, dynamic_cast это явно не важнейшая задача для reflection, добавил в список больше для примера.