Início / coding / Perguntas / 79043075
Accepted
edrezen
Asked: 2024-10-01 20:09:38 +0800 CST

Interpretação de duas cláusulas complexas requer

  • 772

Este post fala sobre um método que conta o número de membros de uma classe:

struct UniversalType { template<typename T> operator T();  };

template<typename T, typename... A0>
consteval auto MemberCounter(auto ...c0) 
{
    if constexpr (requires { T{ {A0{}}..., {UniversalType{}}, c0... }; } == false
               && requires { T{ {A0{}}..., c0..., UniversalType{}   }; } == false )
   {
        return sizeof...(A0) + sizeof...(c0);
    }
    else if constexpr (requires { T{ {A0{}}..., {UniversalType{}}, c0... }; })
    {
        return MemberCounter<T,A0...,UniversalType>(c0...);
    }
    else
    {
        return MemberCounter<T,A0...>(c0...,UniversalType{});
    }
}

using TestType = struct { int x[3]; float y; char z; };
static_assert (MemberCounter<TestType>() == 3);

int main() {}

Em particular, as duas requirescláusulas a seguir me intrigam um pouco, pois misturam chaves simples e duplas:

  1. requires { T{ {A0{}}..., {UniversalType{}}, c0... }; }
  2. requires { T{ {A0{}}..., c0..., UniversalType{} }; }

Pergunta: que tipo de itens eles permitem combinar exatamente?

c++

1 respostas

  1. Best Answer

    A dica está em TestType, que foi deliberadamente projetado para demonstrar o problema que o aninhamento {}resolve.

    A premissa de contar variáveis ​​de membro é verificar o número máximo de argumentos que o tipo aceitará na inicialização agregada. Isso pode ser feito sem saber o tipo dos membros por meio de UniversalType, que pode fingir ser qualquer tipo. Por exemplo

    struct X { int a, b; };
X{UniversalType{}};                                    // compiles
X{UniversalType{}, UniversalType{}};                   // compiles
X{UniversalType{}, UniversalType{}, UniversalType{}};  // doesn't compile

    que nos diz que Xtem duas variáveis ​​de membro.

    Há um problema com isso: a inicialização agregada inicializa subobjetos recursivamente. Então, por exemplo

    struct Y { int a[2], b; };
Y{UniversalType{}};                                    // compiles
Y{UniversalType{}, UniversalType{}};                   // compiles
Y{UniversalType{}, UniversalType{}, UniversalType{}};  // compiles?!

    Para remediar isso, um aninhado extra {}é introduzido. Cada {UniversalType{}}or {A0{}}pode inicializar apenas um único subobjeto, mesmo que seja um agregado, resolvendo o problema.

    Embora pareça que {UniversalType{}}pode inicializar qualquer tipo, há uma exceção: um agregado vazio. Então precisamos testar para ambos {UniversalType{}}e UniversalType{}.

    Dito isto, há vários casos extremos que estão errados com essa implementação.

    struct B
{
    B(int, int) {}
};

struct A
{
    int i;
    B b;
};

struct E
{
};

struct C
{
    E e;
    int i[3];
};

static_assert(std::is_aggregate_v<A> && MemberCounter<A>() != 2);
static_assert(std::is_aggregate_v<C> && MemberCounter<C>() != 2);

    Para A, A{UniversalType{}}falha porque o segundo membro bnão pode ser inicializado por padrão, então o contador retorna 0. Isso pode ser corrigido contando para baixo em vez de para cima.

    Para C, o problema é um pouco mais fundamental. A implementação não tem como lembrar onde os agregados vazios estão. Como {A0{}}precede c0, nenhum agregado pode seguir um agregado vazio.

    • 8

relate perguntas