Устранение зависимости от порядка типов в вариативных c шаблонных классах - PullRequest
Новая
       91

Устранение зависимости от порядка типов в вариативных c шаблонных классах

0 голосов
/ 28 мая 2020

У меня есть класс, который сводится к следующему: 

template <typename ...Ts>
class Stuff
{
   std::vector<std::variant<std::vector<Ts>...>> v_data;
}

Ts - уникальные типы. Насколько я понимаю, за исключением индексов, нет разницы между std::variant<A, B> и std::variant<B, A>, что означает, что с некоторой осторожностью Stuff также должен быть нечувствительным к порядку. Более того, поскольку варианты могут принимать только одно состояние за раз, не должно возникнуть проблем с обработкой Stuff<A> как Stuff<A, B>, если только go не запрашивает данные типа B от этого экземпляра.

Проблема в том, как разрешить такое преобразование? Я попытался написать оператор преобразования: 

template <typename ...Ts>
template <typename ...Us>
Stuff<Ts...>::operator const Stuff<Us...>&() const
{
  /* some assert ensuring that Us is at least as wide as Ts */
  return &(*this);
}

плюс несколько других версий со static_cast et c, но они не компилируются с некоторыми вариантами недопустимого преобразования этого.

Идея заключается в том, чтобы хранить ссылки (_wrapper) на экземпляры Stuff внутри контейнера и работать с ними вместе, и то, что я не знаю, должно быть в std::reference_wrapper<T>, которое подходит для всех этих Stuff.

Несколько других вещей, которые я рассмотрел:

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

  • хранить вместо этого вариант всех возможных вариантов ссылок на материалы: я не знаю, как «взорвать» введите список ie до go от Stuff<A, B> до Stuff<A>, Stuff<B>, Stuff<A, B>, Stuff<B, A>

Любые предложения приветствуются.

РЕДАКТИРОВАТЬ: извинения за редактирование / столкновение, но позвольте я немного уточню то, что я упомянул в комментариях.

В Перестановка типов P (N, R) во время компиляции есть рабочая реализация для взрыва типов. Это соответствовало бы моей цели, если бы его можно было расширить двумя способами:

1 - способ «суммировать» PermutationN<N, P<A, B, C>> s от 1 до N. На самом деле еще не пытался сделать это из-за трудность в достижении следующего расширения, но это, вероятно, связано с tuple_cat как-то

2- вместо того, чтобы обернуть все это в одну и ту же оболочку, например P<P<A, B>, P<B, A>>, можно использовать разные оболочки, например T<U<A, B>, U<B, A>>. Я пробовал сделать это сам, но поскольку обертки, которые я имею в виду, не могут быть пустыми, в то время как оборудование полагается на P<>, мне нужно как-то преобразовать P в T и U, которых я не знаю. не был очень успешным на

...