Как уменьшить шаблон в настоящее время необходимо для сериализации

На мой взгляд, лучшим универсальным решением является внешний генератор кода C ++ на языке сценариев. Имеет следующие преимущества:

• гибкость: позволяет изменять сгенерированный код в любое время. Это очень хорошо по нескольким причинам:

  • Легко исправляйте ошибки во всех старых поддерживаемых выпусках.
  • Используйте новые функции C ++, если в будущем вы перейдете на C ++ 11 или более позднюю версию.
  • Генерация кода для другого языка. Это очень, очень полезно (особенно если ваша организация большая и / или у вас много пользователей). Например, вы можете вывести небольшую библиотеку сценариев (например, модуль Python), которую можно использовать как инструмент CLI для взаимодействия с оборудованием. По моему опыту, это очень понравилось аппаратным инженерам.
  • Сгенерируйте код GUI (или описания GUI, например, в XML / JSON; или даже веб-интерфейс) — полезно для людей, использующих конечное оборудование и тестеров.
  • Генерация другого вида данных. Например, диаграммы, статистика и т. Д. Или даже сами описания протобуфов.

• техническое обслуживание: это будет легче поддерживать, чем в C ++. Даже если он написан на другом языке, обычно легче выучить этот язык, чем позволить новому разработчику C ++ погрузиться в метапрограммирование шаблонов C ++ (особенно в C ++ 03).

• Спектакль: он может легко сократить время компиляции на стороне C ++ (поскольку вы можете вывести очень простой C ++ — даже простой C). Конечно, генератор может компенсировать это преимущество. В вашем случае это может не применяться, так как похоже, что вы не можете изменить код клиента.

Я использовал этот подход в нескольких проектах / системах, и он получился довольно удачным. Специально различные альтернативы для использования аппаратного обеспечения (C ++ lib, Python lib, CLI, GUI …) могут быть очень оценили.

Примечание: если часть поколения требует разбора уже существует Код C ++ (например, заголовки с сериализуемыми типами данных, как в случае OP с Serialized типов); тогда очень хорошее решение использует Инструменты LLVM / Clang сделать это.

В конкретном проекте, над которым я работал, нам пришлось автоматически сериализовать десятки типов C ++ (которые могли быть изменены в любое время пользователями). Нам удалось автоматически сгенерировать код для этого, просто используя привязки Python и включив его в процесс сборки. Хотя привязки Python не раскрывают всех деталей AST (по крайней мере, на тот момент), их было достаточно для генерации необходимого кода сериализации для всех наших типов (которые включают в себя шаблонные классы, контейнеры и т. Д.).

То, что вы хотите, это то, что Кортеж, как но не фактический кортеж. Предполагая, что все tuple_like классы реализуют tie() который в основном просто связывает их членов, вот мой гипотетический код:

template<typename T> struct tuple_like {
bool operator==(const T& rhs) const {
return this->tie() == rhs.tie();
}
bool operator!=(const T& rhs) const {
return !operator==(*this,rhs);
}
};
template<typename T, typename Serialised> struct serialised_tuple_like : tuple_like<T> {
};
template<typename T, typename Serialised>
struct serialization_traits<serialised_tuple_like<T, Serialised>> {
static Serialised encode(const T& bb) {
Serialised s;
s.tie() = bb.tie();
return s;
}
};

Пока обе стороны реализуют соответствующий tie (), это должно быть хорошо. Если исходный или целевой классы не находятся под вашим непосредственным контролем, рекомендуем определить унаследованный класс, который реализует tie (), и использовать его. Для объединения нескольких классов определите вспомогательный класс, который реализует tie () в терминах его членов.

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

#define POD2(NAME, T0, N0, T1, N1) \
struct NAME { \
T0 N0; \
T1 N1; \
NAME(const T0& N0, const T1& N1) \
: N0(N0), N1(N1) {} \
bool operator==(const NAME& rhs) const { return N0 == rhs.N0 && N1 == rhs.N1; }
\
bool operator!=(const NAME& rhs) const { return !operator==(rhs); } \
};

Использование будет выглядеть так:

POD2(BarBaz, Bar, bar, Baz, baz)

template <>
struct serialization_traits<BarBaz> {
static SerializedBarBaz encode(const BarBaz& bb) {
SerializedBarBaz sbb;
sbb.set_bar(bb.bar);
sbb.set_baz(bb.baz);
return sbb;
}
};

Вам понадобится N макросов, где N — это количество перестановок количества аргументов, которое у вас есть, но это будет единовременная предоплата.

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

#define NAMED_TUPLE2_T(N0, N1) NamedTuple##N0##N1

#define NAMED_TUPLE2(N0, N1) \
template <typename T0, typename T1> \
struct NAMED_TUPLE2_T(N0, N1) { \
typedef std::tuple<T0, T1> TupleType; \
const typename std::tuple_element<0, TupleType>::type& N0() const { return std::get<0>(tuple_); } \
const typename std::tuple_element<1, TupleType>::type& N1() const { return std::get<1>(tuple_); } \
NAMED_TUPLE2_T(N0, N1)(const std::tuple<T0, T1>& tuple) : tuple_(tuple) {} \
bool operator==(const NAMED_TUPLE2_T(N0, N1)& rhs) const { return tuple_ == rhs.tuple_; } \
bool operator!=(const NAMED_TUPLE2_T(N0, N1)& rhs) const { return !operator==(rhs); } \
private: \
TupleType tuple_; \
}; \
typedef NAMED_TUPLE2_T(N0, N1)

Использование:

NAMED_TUPLE2(foo, bar)<int, int> FooBar;

template <>
struct serialization_traits<FooBar> {
static SerializedFooBar encode(const FooBar& fb) {
SerializedFooBar sfb;
sfb.set_foo(fb.foo());
sfb.set_bar(fb.bar());
return sfb;
}
};

Рассматривали ли вы немного другой подход? Вместо того, чтобы иметь отдельное представление FooBar и BarBaz, рассмотрим FooBarBaz, аналогичный

message FooBarBaz {
optional Foo foo = 1;
optional Bar bar = 2;
optional Baz baz = 3;
}

И затем в коде приложения вы можете воспользоваться этим, например:

FooBarBaz foo;
foo.set_foo(...);
FooBarBaz bar;
bar.set_bar(...);
FooBarBaz baz;
baz.set_baz(...);
FooBarBaz foobar = foo;
foobar.MergeFrom(bar);
FooBarBaz barbaz = bar;
barbaz.MergeFrom(baz);

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

// assume string_foo is the actual serialized foo from above, likewise string_bar
string serialized_foobar = string_foo + string_bar;
string serialized_barbaz = string_bar + string_baz;

FooBarBaz barbaz;
barbaz.ParseFromString(serialized_barbaz);

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