Como trabalhar de forma limpa com a classe enum e uint8_t sem static_cast excessivo?

Mas isso rapidamente se transformou em um milhão de combinações possíveis de tipos de enumeração e uint8_t

Seu código não demonstra essa necessidade. Ela pode existir no seu código real, mas, ao mesmo tempo, você pode estar tentando criar problemas demais e lidar com muitos problemas de uma só vez. Em vez de tratar isso como um problema monolítico, divida para conquistar. Vejo quatro problemas distintos que podem ser resolvidos individualmente.

1. É muito provável que seus NBvalores sejam usados ​​como números em vez de enumeradores. Portanto, defina constantes para eles com o tipo inteiro desejado. Isso permite que você pule a conversão onde esses números são usados.

constexpr u8 SquareCount = static_cast<u8>(Square::NB);
constexpr u8 ColorCount = static_cast<u8>(Color::NB);
constexpr u8 PieceCount = static_cast<u8>(PieceType::NB);

2. O único operador aritmético que seu código de demonstração precisa é incrementar um Square. Isso é fácil de adicionar e, como um operador unário, não há necessidade intrínseca de levar em conta combinações com outros tipos.

Square& operator++(Square& src) noexcept {
    src = static_cast<Square>(1 + static_cast<u8>(src));
    return src;
}

3. Embora suas funções getFilee getRanksejam boas, elas são a causa de alguns dos seus problemas. Elas devem ser complementadas por funções paralelas que omitam a conversão final; ou seja, que retornem u8. Eu usaria "Number" como sufixo para indicar que o valor de retorno é um número, adequado para uso em cálculos. Você pode querer modificar getFilee getRankchamar essas novas funções para evitar repetir a aritmética.

constexpr u8 getFileNumber(Square sq) {
    return static_cast<u8>(sq) % 8;
}

constexpr u8 getRankNumber(Square sq) {
    return static_cast<u8>(sq) / 8;
}

4. Os subscritos são um problema mais espinhoso porque operator[]não podem ser definidos fora de uma classe. Então, minha solução seria definir uma classe para encapsular seu array. Você pode descobrir que isso também traz outros benefícios, como a possibilidade de mover precomputeSquareDistancepara o construtor. E não apenas um construtor, mas um constexprconstrutor (os valores podem ser computados durante a compilação em vez de em tempo de execução).

class Distances {
    std::array<std::array<u8, SquareCount>, SquareCount> squares;

    public:
        // Note: C++23 feature used here. For earlier versions, this takes
        // a bit more boilerplate.
        constexpr u8& operator[](Square s1, Square s2) {
            return squares[static_cast<u8>(s1)][static_cast<u8>(s2)];
        }
        // There should also be a `const` version. That complication is routine
        // and left to the reader.

        constexpr Distances() {
            for (Square s1 = Square::FIRST; s1 <= Square::LAST; ++s1) {
                for (Square s2 = Square::FIRST; s2 <= Square::LAST; ++s2) {
                    // Note the comma between the subscripts rather than using
                    // two pairs of square brackets.
                    (*this)[s1, s2] =
                        std::abs(getFileNumber(s1) - getFileNumber(s2)) +
                        std::abs(getRankNumber(s1) - getRankNumber(s2));
                }
            }
        }
};

Em conjunto, essas mudanças reduzem as ocorrências de static_castno seu código de demonstração de 25 para 10. O ponto principal é que, além de uma conversão na mainfunção, as conversões foram movidas para funções utilitárias e constantes. As utilidades são o que é usado repetidamente, não static_castdiretamente. Pode haver mais utilidades necessárias no seu código real, mas pode não ser tão ruim quanto você pensava. Principalmente se você parar de dificultar as coisas para si mesmo (veja o nº 3).

Reconheço a resposta sobre o uso de enumerações sem escopo dentro de um namespace como outra abordagem razoável. Certamente vale a pena considerar se você não conseguir mover conversões suficientes do seu código real para funções utilitárias.

Para referência, a função principal após a introdução do acima:

int main() {
    std::cout << static_cast<int>(squareDistance[Square::A1, Square::H8]) << "\n";
    return 0;
}

O static_castque permanece nesta função é um artefato do uso uint8_te não está relacionado ao uso de enumerações com escopo.

Como @NathanOliver sugeriu nos comentários acima, use enumerações sem escopo dentro de um namespace. Valores de enumerações sem escopo podem ser promovidos ou convertidos para tipos integrais. O contrário pode ser feito usando static_cast.

Com isso em mente, você pode fazer o seguinte:

//enum class File : u8
namespace File {
    enum value : u8 {/* ... */}; //name is optional
}

//enum class Square : u8
namespace Square {
    enum value : u8 {/* ... */}; //name is optional

    //to circumvent the "ugliness" below
    //and if we're going to use auto, 
    //then we wouldn't have to name the enum (if desired)
    constexpr auto toFile(auto sq) {
        return sq % 8;
    }
}

//this might look a bit ugly
//if we were dealing with unnamed enums, 
//then we would have to use the underlying type (u8 or auto) instead,
//but then, function overloading would go out of the window
constexpr File::value getFile(Square::value sq) {
    return static_cast<File::value>(sq % 8); //int to enum: need static_cast here
}

//but this looks much better (some gain, some loss)
std::array<std::array<u8, Square::NB>, Square::NB> squareDistance{};

Acho que isso deve cobrir a ideia. Lembre-se de que a promoção e a conversão para o tipo integral são implícitas. A conversão para um valor enum pode ser feita explicitamente usando a static_cast(desde que não exceda o intervalo de valores, UB caso contrário).

1. use função auxiliar ou macros: defina função utilitária para encapsular a conversão:

   cpp

   constexpr unit8_t to_unit8(valor enumClass)

   static_cast<unit8_t>(value)