Решения для динамической отправки на несвязанные типы

Я исследую возможные реализации динамической диспетчеризации несвязанных типов в современном C ++ (C ++ 11 / C ++ 14).

Под «динамической диспетчеризацией типов» я имею в виду случай, когда во время выполнения нам нужно выбрать тип из списка по его интегральному индексу и что-то с ним сделать (вызвать статический метод, использовать черту типа и т. Д.).

Например, рассмотрим поток сериализованных данных: существует несколько видов значений данных, которые сериализуются / десериализуются по-разному; есть несколько кодеков, которые делают сериализацию / десериализацию; и наш код читает маркер типа из потока, а затем решает, какой кодек он должен вызывать для считывания полного значения.

Меня интересует случай, когда существует много операций, которые могут быть вызваны для типов (несколько статических методов, черты типов …), и где может быть другое отображение из логических типов в классы C ++, а не только 1: 1 (в Например, с сериализацией это означает, что может быть несколько типов данных, которые все сериализуются одним и тем же кодеком).

Я также хотел бы избежать повторения кода вручную и сделать его более легким в обслуживании и менее подверженным ошибкам. Производительность также очень важна.

В настоящее время я вижу эти возможные реализации, я что-то упустил? Можно ли сделать это лучше?

1. Вручную напишите столько функций с помощью switch-case, сколько существует возможных вызовов операций над типами.

   size_t serialize(const Any & any, char * data)
   {
   switch (any.type) {
   case Any::Type::INTEGER:
   return IntegerCodec::serialize(any.value, data);
   ...
   }
   }
   Any deserialize(const char * data, size_t size)
   {
   Any::Type type = deserialize_type(data, size);
   switch (type) {
   case Any::Type::INTEGER:
   return IntegerCodec::deserialize(data, size);
   ...
   }
   }
   bool is_trivially_serializable(const Any & any)
   {
   switch (any.type) {
   case Any::Type::INTEGER:
   return traits::is_trivially_serializable<IntegerCodec>::value;
   ...
   }
   }
   

Pros: это просто и понятно; Компилятор может встроить отправленные методы.

Cons: это требует много ручного повторения (или генерации кода с помощью внешнего инструмента).

2. Создайте таблицу диспетчеризации, как это

   class AnyDispatcher
   {
   public:
   virtual size_t serialize(const Any & any, char * data) const = 0;
   virtual Any deserialize(const char * data, size_t size) const = 0;
   virtual bool is_trivially_serializable() const = 0;
   ...
   };
   class AnyIntegerDispatcher: public AnyDispatcher
   {
   public:
   size_t serialize(const Any & any, char * data) const override
   {
   return IntegerCodec::serialize(any, data);
   }
   Any deserialize(const char * data, size_t size) const override
   {
   return IntegerCodec::deserialize(data, size);
   }
   bool is_trivially_serializable() const
   {
   return traits::is_trivially_serializable<IntegerCodec>::value;
   }
   ...
   };
   ...
   
   // global constant
   std::array<AnyDispatcher *, N> dispatch_table = { new AnyIntegerDispatcher(), ... };
   
   size_t serialize(const Any & any, char * data)
   {
   return dispatch_table[any.type]->serialize(any, data);
   }
   Any deserialize(const char * data, size_t size)
   {
   return dispatch_table[any.type]->deserialize(data, size);
   }
   bool is_trivially_serializable(const Any & any)
   {
   return dispatch_table[any.type]->is_trivially_serializable();
   }
   

Prosэто немного более гибко — нужно написать класс диспетчера для каждого отправляемого типа, но затем можно объединить их в разных таблицах диспетчеризации.

Cons: это требует написания большого количества диспетчерского кода. И есть некоторые издержки из-за виртуальной диспетчеризации и невозможности встроить методы кодека на сайт вызывающей стороны.

3. Используйте шаблонную функцию диспетчеризации

   template <typename F, typename... Args>
   auto dispatch(Any::Type type, F f, Args && ...args)
   {
   switch (type) {
   case Any::Type::INTEGER:
   return f(IntegerCodec(), std::forward<Args>(args)...);
   ...
   }
   }
   
   size_t serialize(const Any & any, char * data)
   {
   return dispatch(
   any.type,
   [] (const auto codec, const Any & any, char * data) {
   return std::decay_t<decltype(codec)>::serialize(any, data);
   },
   any,
   data
   );
   }
   bool is_trivially_serializable(const Any & any)
   {
   return dispatch(
   any.type,
   [] (const auto codec) {
   return traits::is_trivially_serializable<std::decay_t<decltype(codec)>>::value;
   }
   );
   }
   

Pros: для этого требуется только одна функция диспетчеризации переключателя и немного кода в каждом вызове операции (по крайней мере, вручную). И компилятор может включить то, что он считает подходящим.

Cons: это более сложно, требует C ++ 14 (чтобы быть таким чистым и компактным) и полагается на способность компилятора оптимизировать удаление неиспользуемого экземпляра кодека (который используется только для выбора правильной перегрузки для кодека).

4. Когда для одного набора логических типов может быть несколько отображений на классы реализации (в этом примере кодеки), может быть лучше обобщить решение № 3 и написать полностью универсальную функцию диспетчеризации, которая получает отображение времени компиляции между значениями типов и вызываемыми типами , Что-то вроде этого:

   template <typename Mapping, typename F, typename... Args>
   auto dispatch(Any::Type type, F f, Args && ...args)
   {
   switch (type) {
   case Any::Type::INTEGER:
   return f(mpl::map_find<Mapping, Any::Type::INTEGER>(), std::forward<Args>(args)...);
   ...
   }
   }
   

Я опираюсь на решение № 3 (или № 4). Но я удивляюсь — можно ли избежать написания вручную dispatch функционировать? Я имею ввиду его распределительный шкаф. Этот случай переключения полностью получен из отображения времени компиляции между значениями типа и типами — есть ли способ обработать его генерацию для компилятора?