Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / С++ как узнать смещение классов при виртуальном наследовании? (2 стр)

С++ как узнать смещение классов при виртуальном наследовании? (2 стр)

Поделиться

Страницы: 1 2

anzПостоялецwww29 окт. 201716:20#15
loyso
> Обычно поля с конкретной целью вытаскивают/засылают - анимация, репликация,
> сериализация, скриптинг, редактирование или все вместе.
а можно это поподробнее? не понял )

Вообще, вся эта рефлексия как раз для всего этого, анимация, сериализация, скриптинг и тд

У меня есть идея как это все сделать по-другому, но переделывать довольно долго. Суть примерно такая:
у меня есть возможность сгенерировать код со описанием методов, переменных и базовых типов класса. Поэтому вместо функции инициализации типа я могу сделать какую-нибудь универсальную шаблонную функцию, где в шаблоне передавать некий обработчик данных о классе.

struct MyClass: public IBase
{
  int abc;
  float def;
  string abba;

  template<typename TypeProcessor>
  void ProcessType(TypeProcessor& processor)
  {
    ProcessType(this, processor);
  }

  template<typename TypeProcessor>
  static void ProcessType(MyClass* target, TypeProcessor& processor)
  {
    processor.Start(target);

    processor.BaseClass<IBase>(target, "IBase");

    processor.Field<int>(abc, "abc");
    processor.Field<float>(def, "def");
    processor.Field<string>(abba, "abba");

    ...
  }
};
И в качестве TypeProcessor я могу просовывать что душе угодно, хоть инициализатор типа, хоть поиск поля по имени, правда код будет немного раздутый. И, по-идее, тут не будет никаких проблем с UB, тк все будет явно и без хаков. Какого хрена сразу так не стал делать...

Правка: 29 окт. 2017 16:22

loysoПостоялецwww29 окт. 201717:11#16
anz
> И в качестве TypeProcessor я могу просовывать что душе угодно, хоть
> инициализатор типа, хоть поиск поля по имени
Да, это visitor фактически. Можно даже без шаблонов, в рантайм обходить объекты типов и собирать мета-информацию - это все несущественные детали.
Лучше отцепить функции и сделать вне класса - улучшить decoupling.
Можно насоветовать всяких pointer-to-member (&A::m_a синтаксис), но все это закончится нестандартными offsetof так или иначе.
(Тебе еще надо будет подумать над линейным наследованием и как работать с полиморфными объектами, на которые
есть только указатель базового типа. Плюс вспомнить что надо рефлексировать не только наполнение объектов, но и сами полиморфные объекты и отношения между ними - ссылки, граф объектов, агрегацию etc).

Так вот - все это будет работать, да. Но возможности будут довольно ограничены (ограниченная расширяемость, слишком сильная сцепленность coupling и сплоченность cohesion).
C++ тут не силен пока, а Generative C++ и в 20м стандарте не видать.

Есть альтернатива - иметь мета-инфу во внешнем файле-проекте (некоторая Модель. Это структура объектов и отношений между ними)
В xml, json, свой простой recursive parser просто писать:

typeinfo MyClass {
  int abc
  float def
  string abba
}
И из нее уже печатать независимо нужный код подсистем редактора там или игры. (через любой text-template движок, например).
Т.е. "проецировать Модель на подсистему". В виде классов и кода, которые той конкретной подсистеме нужны.
Это даст тебе возможность меняя мета-файл менять "вертикальный срез" вообще всех подсистем.
Естественно, придется продумать как автогенереный код композитится с кодом ручного написания.

Правка: 29 окт. 2017 17:18

anzПостоялецwww29 окт. 201717:50#17
loyso
хмм интересно )) А не будет ли это аналогично шаблонному visitor'у? Что сгенерированный код, что visitor будут делать по-сути одно и то же. Возможно я просто не понял почему именно будут ограничены возможности visitor'а :\
*Lain*Пользовательwww29 окт. 201719:01#18
loyso
> А кто тебе сказал что объект будет в памяти непрерывным в этом случае? Стандарт не гарантирует.
гарантирует. кусок памяти неприрывен
*Lain*Пользовательwww29 окт. 201719:08#19
boost::serialize. юзай готовое. пока ты на пути к нерабочему велосипеду
Kollect3DПостоялецwww29 окт. 201719:24#20
Overlordff
> offsetof не может быть реализован средствами текущего стандарта C++

По моему это высказывание не соответствует истине.
Вот, например, вот такой эксерсиз сразу же приходит на ум: https://ideone.com/rch7hI , дальше его только обмазать шаблонами и/или макросами и вуаля. Собственно оно тоже начнёт само естественным образом ругаться если туда засунуть не-POD-тип. Не нужны ему для этого никакие builtin-ы.
Проблема там поэтому не в нулл-дереференс, а в отношении так сказать. Почему комитет и все обсуждающие эту фишку упорно продолжают настаивать на дереференсе там где его нет - ну да бог им судья. Главное что создатели компиляторов сделали как правильно.

Правка: 29 окт. 2017 19:26

loysoПостоялецwww30 окт. 20179:09#21
anz
> Что сгенерированный код, что visitor будут делать по-сути одно и то же.
> Возможно я просто не понял почему именно будут ограничены возможности visitor'а
> :\
Каждый Сиплюсплюс Воин должен сделать свою сериализацию на шаблонах!
Только так можно достигнуть просветления.
innuendoПостоялецwww30 окт. 201710:45#22
loyso
> Каждый Сиплюсплюс Воин должен сделать свою сериализацию на шаблонах!
> Только так можно достигнуть просветления.

Вот тут согласен полностью - что каждый должен свой путь пройти, а не лекции слушать :):):)

Страницы: 1 2

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр