Мета-программирование атрибутов для сериализации / forpes.ru

Главная
Мета-программирование атрибутов для сериализации

Мета-программирование атрибутов для сериализации +5

21.05.2021 13:55

anz 6 2400 Источник

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

В движке рефлексия используется для сериализации. Вкратце работает так:

Описываем класс, сериализуемые поля отмечаем атрибутом, через комментарии

struct MyClass: public ISerializable
{
	int _myAValue = 0; // @SERIALIZABLE
	int _myBValue = 0; // @SERIALIZABLE
	int _myCValue = 0; 
	int _myDValue = 0; 
};

Утилита кодгена парсит класс, генерирует код-описание класса на макросах

CLASS_FIELDS_META(MyClass)
{
	FIELD().DEFAULT_VALUE(0).SERIALIZABLE().NAME(_myAValue);
	FIELD().DEFAULT_VALUE(0).SERIALIZABLE().NAME(_myBValue);
	FIELD().DEFAULT_VALUE(0).NAME(_myCValue);
	FIELD().DEFAULT_VALUE(0).NAME(_myDValue);
}

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

template<typename Processor>
void MyClass::ProcessFields(Processor& processor, MyClass* object)
{
  processor.BeginField().SetDefaultValue(0).AddAttribute<SerializableAttribute>().Complete(object, "_myAValue", object->_myAValue);
  processor.BeginField().SetDefaultValue(0).AddAttribute<SerializableAttribute>().Complete(object, "_myBValue", object->_myBValue);
  processor.BeginField().SetDefaultValue(0).Complete(object, "_myCValue", object->_myCValue);
  processor.BeginField().SetDefaultValue(0).Complete(object, "_myDValue", object->_myDValue); 
}

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

struct JsonSerializeProcessor
{  
  // Вызывается при старте обработки поля класса
  FieldProcessor BeginField() const { return FieldProcessor(); }
  
  // Обработчик поля класса
	struct FieldProcessor
  {        
  	template<typename T>
  	FieldProcessor& SetDefaultValue(const T& value) { ...; return *this; }
    
    template<typename T, typename ... Args>
    FieldProcessor& AddAttribute(Args ... args) { ...; return *this; }
    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    { 
      json[name] = *fieldPtr; //Здесь пишем в json значение
    }
  };
};

Рассмотрим обработку одного поля этим обработчиком

processor.BeginField() 
 // Возвращаем FieldProcessor
.SetDefaultValue(0)    
 // Запоминаем дефолтное значение и возвращаем FieldProcessor&
.AddAttribute<SerializableAttribute>()
 // Добавляем во внутренний список аттрибут и снова возвращаем FieldProcessor&
.Complete("_myAValue", object->_myAValue);
 // Здесь пишем значение в json

Этот обработчик сериализует все поля. Но на не нужно сериализвать все, а только те что помечены специальным атрибутом.

Можно искать нужный атрибут в списке, но это долго и расточительно.

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

Здесь на помощь приходит dead code ellimination. Это оптимизация компилятора, которая выкидывает мертвые куски кода, которые ни к чему не приводят. То есть их можно удалить без изменения поведения программы. Например пустые функции.

Что ж, осталось написать наш шаблонный обработчик так, чтобы он выдавал dead code если нет соответствующего атрибута.

struct JsonSerializeProcessor
{  
  // Вызывается при старте обработки поля класса
  FieldProcessor BeginField() const { return FieldProcessor(); }
  
	// Мертвый процессор поля класса, который ничего не делает
	struct DeadProcessor
  {
  	template<typename T>
  	DeadProcessor& SetDefaultValue(const T& value) { return *this; }
    
    template<typename T, typename ... Args>
    DeadProcessor& AddAttribute(Args ... args) { return *this; }
    
    template<typename ObjectType, typename T>
		void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    {} // Тут компилятор поймет что код ничего не делает
  };
  
  // Обработчик поля класса, который умеет реагировать на атрибуты
	struct FieldProcessor
  {    
    template<typename T, typename ... Args>
    auto AddAttribute(Args ... args) 
    { 
      // Если тип аттрибута не подходит, возвращаем процессор, который приводит к
      // dead code
      if constexpr (!std::is_same<T, SerializableAttribute>::value)
      	return DeadProcessor();
        
    	return *this; 
    }
    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    { 
      json[name] = *fieldPtr; //Здесь пишем в json значение
    }
    
  	template<typename T>
  	FieldProcessor& SetDefaultValue(const T& value) { ...; return *this; }
  };
};

Самое интересное место здесь - FieldProcessor::AddAttribute. Именно эта функция меняет поведение в зависимости от типа T. Если этот тип не атрибут сериализации - возвращаем DeadProcessor, который ничего не делает. Иначе, позвращаем себя и в Complete успешно пишем поле в json. Так же нам приходится использовать auto в качестве возвращаемого значения, ведь фактически оно бывает разных типов (FieldProcessor& или DeadProcessor).

Вышло хитро, но не расширяемо. Он умеет реагировать только на один тип атрибута - SerializableAttribute. В идеале бы сделать так, чтобы сам атрибут определял поведение обработчика поля.

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

Для этого будем использовать паттерн mixin'ов - это шаблонные классы, которые могут добавить к какому-либо классу определенный функционал, без привязки к базовому классу. Например:

template<typename Base>
struct Mixin: public Base
{
	void MyFunction();
};

class A { int a; };
class B { int b; };

class C: public Mixin<A> {}; // Добавляем функционал Mixin к классу A
class D: public Mixin<B> {}; // Добавляем функционал Mixin к классу B

Теперь попробуем этот подход применить к обработчику полей класса и атрибутам.

Сделаем так, чтобы FieldProcessor мог дополнять себя mixin'ами из атрибутов. И перенесем запись json в mixin атрибута сериализации:

struct SerializableAttribute
{
  // Определим mixin, который будет заниматься записью в json
  template<typename Base>
  struct FieldProcessorMixin: public Base
  {    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    { 
      json[name] = *fieldPtr; //Здесь пишем в json значение
    }
  };
};

struct JsonSerializeProcessor
{    
  // Вызывается при старте обработки поля класса
  FieldProcessor BeginField() const { return FieldProcessor(); }
  
  // Обработчик поля класса, который умеет реагировать на атрибуты
	struct FieldProcessor
  {        
    template<typename T, typename ... Args>
    auto AddAttribute(Args ... args)
    {
      // С помощью шаблонной магии проверяем определен ли класс FieldProcessorMixin
      // в аттрибуте T. Если да - возращаем mixin Из него
      if constexpr (HasFieldProcessorMixin<T>::value)
        return T::FieldProcessorMixin<FieldProcessor>();
      
      return *this;
    }
    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    {} // Теперь тут ничего не делаем, запись перенесена в mixin
    
  	template<typename T>
  	FieldProcessor& SetDefaultValue(const T& value) { ...; return *this; }
  };
};

Окей, теперь посмотрим как эта конструкция сработает на примере сериализуемого поля класса:

processor.BeginField() 
 // Тут возвращаем наш базовый FieldProcessor
.SetDefaultValue(0)    
 // Все еще возвращаем FieldProcessor
.AddAttribute<SerializableAttribute>()
 // Тут уже вернется SerializableAttribute::FieldProcessorMixin<FieldProcessor>
.Complete("_myAValue", object->_myAValue);
 // Вызовется SerializableAttribute::FieldProcessorMixin<FieldProcessor>::Complete,
 // которая запишет значение в json

и как для не сериализуемого поля:

processor.BeginField() 
 // Тут возвращаем наш базовый FieldProcessor
.SetDefaultValue(0)    
 // Все еще возвращаем FieldProcessor
.Complete("_myСValue", object->_myСValue);
 // Вызовется FieldProcessor::Complete,
 // которая ничего не делает. Компилятор вырежет эту цепочку вызовов полностью

Класс! Мы через класс атрибута меняем поведение обработчика! Однако, здесь есть нюанс - это работает только если у поля задан один единственный атрибут. Mixin в качестве базового класса всегда получает FieldProcessor, и забывает о предыдущих атрибутах.

T::FieldProcessorMixin<FieldProcessor>()

То есть в Base мы как-то должны передавать все накопленные mixin'ы.

К сожалению единственное решение - в каждом mixin'е атрибутов определять метод AddAttribute. Что ж, попробуем хотя бы обобщить:

struct SerializableAttribute
{
  // Определим mixin, который будет заниматься записью в json
  template<typename Base>
  struct FieldProcessorMixin: public Base
  {
    // Добавляем технический метод добавления аттрибута,
    // Который вполне можно завернуть в макрос ATTRIBUTE()
    template<typename T, typename ... Args>
    auto AddAttribute(Args ... args)
    {
      // Используем обобщенную функцию FieldProcessor::AddAttributeImpl 
      // В качестве Base передаем текущий тип класса, в котором уже накоплены
      // все предыдущие Mixin'ы
      return Base::AddAttributeImpl<T, FieldProcessorMixin<Base>, Args ...>(args ...);
    }
    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    { 
      json[name] = *fieldPtr; //Здесь пишем в json значение
    }
  };
};

struct JsonSerializeProcessor
{    
  // Вызывается при старте обработки поля класса
  FieldProcessor BeginField() const { return FieldProcessor(); }
  
  // Обработчик поля класса, который умеет реагировать на аттрибуты
	struct FieldProcessor
  {    
    // Обобщенная функция с шаблонным Base
    template<typename T, typename Base, typename ... Args>
    auto AddAttributeImpl(Args ... args)
    {
      if constexpr (HasFieldProcessorMixin<T>::value)
        return T::FieldProcessorMixin<Base>(args ...);
    }
    
    template<typename T, typename ... Args>
    auto AddAttribute(Args ... args) 
    { 
      // Используем обобщенный метод, в Base передаем сами себя
      return AddAttributeImpl<T, FieldProcessor, Args ...>(args ...);
    }
    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    {} // Тут ничего не делаем, запись перенесена в mixin
    
  	template<typename T>
  	FieldProcessor& SetDefaultValue(const T& value) { ...; return *this; }
  };
};

Теперь нужен какой-то пример, чтобы увидеть систему в действии. Добавим атрибут, который добавляет условие к сериализации.

struct SerializeIfAttribute
{
  // Определим mixin, который вызывает функцию IsSerializable у object, и вызывает
  // базовый Complete, если она возвращает true
  template<typename Base>
  struct FieldProcessorMixin: public Base
  {
    // Используем макрос
    ATTRIBUTE();
    
    template<typename ObjectType, typename T>
    void Complete(ObjectType* object, const char* name, T* fieldPtr) 
    { 
      // Вызов определенной функции
      if (object->IsSerializable())
      	Base::Complete(name, fieldPtr);
    }
  };
};

Посмотрим как это работает:

processor.BeginField() 
 // Тут возвращаем наш базовый FieldProcessor
.SetDefaultValue(0)    
 // Все еще возвращаем FieldProcessor
.AddAttribute<SerializableAttribute>()
 // Тут уже вернется SerializableAttribute::FieldProcessorMixin<FieldProcessor>
.AddAttribute<SerializeIfAttribute>()
 // Тут уже вернется SerializeIfAttribute::FieldProcessorMixin<SerializableAttribute::FieldProcessorMixin<FieldProcessor>>
.Complete("_myAValue", object->_myAValue);
 // В этой функции сначала вызовется преверка функции в SerializeIfAttribute::FieldProcessorMixin::Complete
 // Если она проходит, то вызывается SerializableAttribute::FieldProcessorMixin::Complete
 // Которая уже запишет значение в json

С помощью mixin'ов можно добавить проверку дефолтного значения, чтобы не записывать их в json.

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

Пожалуй более лучшим решением было бы просто генерировать специальный код под разные назначения. Это было бы максимально эффективно, но, пожалуй, не так гибко. Ведь пришлось бы изменять код кодгена.

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

Комментарии (6)

MomoDev
22.05.2021 12:41
#23065962
Идея интересная, но боюсь на большой кодовой базе, когда такие шаблоны генерируются под каждый класс, билд тайм будет значительно замедляться. В целом понятно, как c помощью шаблонов и визитора сериализовать или отобразить поля класса, но как таким способом проделать обратную операцию, т.е. по json восстановить объект?
1. anz Автор
  22.05.2021 18:21
  #23066702
  По json восстановить объект — собственно то же самое, только вместо записи происходит чтение поля из json. В статье конечно код сильно упрощен, но в движке все поддерживается.
  
  Кода генерится и правда много, но не больше чем если бы он генерился просто для сериализации. Здесь ведь просто специализация шаблона. А типы повторяются. Тоже самое почти что

ivfilin
22.05.2021 18:13
#23066680
имеет смысл смотреть в сторону:
boost::hana::BOOST_HANA_ADAPT_STRUCT — для обозначения мемберов класса/структуры под сериализацию.
nlohman::json секцию adl_serializer — для перевода в json и обратно

Racheengel
22.05.2021 23:43
#23067320
У нас было подобное решение с шаблонами-миксинами и кодогенератором на одном старом проекте... В результате проект собирался вечность, дебагать нагенеренное было практически невозможно, да и итоговая производительность не радовала. Выкинули вот это вот всё - полегчало) правда)
1. anz Автор
  23.05.2021 07:38
  #23067684
  На что заменили? У вас тоже сериализация была? У меня вроде не оч заметно, пока что )
  1. Racheengel
    23.05.2021 09:42
    #23067812
    Шаблоны заменили на проперти-классы, которые объединены в структуру типа дерева. Сериализацию, соответственно, на чтение и запись дерева. Это позволило сохранить совместимость со старыми версиями файлов, где порядок и количество параметров отличалось.
    И от кодогенератора избавились. Ни к чему оно.

Мета-программирование атрибутов для сериализации +5

Комментарии (6)

MomoDev

anz Автор

ivfilin

Racheengel

anz Автор

Racheengel