Énumération non scopée, énumérateur et ambiguïté de type sous-jacent en C ++

Le type sous-jacent est défini par l'implémentation. Il doit seulement être capable de représenter tous les énumérateurs, et il ne peut pas être plus grand que int sauf si nécessaire. Il n'y a aucune exigence sur la signature (mis à part le fait que le type de base doit pouvoir représenter chaque énumérateur), selon dcl.enum.7 , comme vous l'avez déjà trouvé. Cela limite la rétro-propagation des types d'énumérateurs plus que vous ne semblez le supposer. Notamment, il ne dit nulle part que le type de base de l'énumération doit être le type de l'un des initialiseurs des énumérateurs.

Clang préfère les entiers non signés comme bases d'énumération aux entiers signés; c'est tout ce qu'on peut en dire. Il est important de noter que le type de l'énumération ne doit pas nécessairement correspondre au type d'un énumérateur spécifique: il doit seulement être capable de représenter chaque énumérateur. C'est assez normal et bien compris dans d'autres contextes. Par exemple, si vous aviez EN_1 = 1 , cela ne vous surprendrait pas que le type de base de l'énumération ne soit pas int ou unsigned int , même si 1 est un int.

Vous avez également raison de dire que le type de 0x7fffffffffffffff est long . Clang est d'accord avec vous, mais convertit implicitement la constante en unsigned long :

template<typename T>
T tell_me(const T&& value);

enum Foo {
    Baz = 0x7ffffffffffffff
};

int main() {
    tell_me(Baz);
    // call    Foo tell_me<Foo>(Foo const&&)
}

Ceci est autorisé, car comme nous l'avons déjà dit, le type de base de l'énumération n'a pas besoin d'être le type textuel de n'importe quel énumérateur.

Quand la norme dit que chaque énumérateur a le type de l'énumération, cela signifie que le type de EN_1 est enum UEn après l'accolade de fermeture de l'énumération. Notez les mentions «après l'accolade fermante» et «avant l'accolade fermante».

Avant l'accolade fermante, si l'énumération n'a pas de type fixe, alors le type de chaque énumérateur est celui de son initialisation type d'expression, mais ce n'est que temporaire. C'est ce qui vous permet, par exemple, d'écrire EN_2 = EN_1 + 1 sans lancer EN_1 , même dans le cadre d'une classe enum . Ce n'est plus vrai après l'accolade fermante. Vous pouvez tromper le compilateur en vous montrant en inspectant les messages d'erreur ou en regardant le désassemblage:

template<typename T>
T tell_me(const T&& value);

enum Foo {
    Baz = 0x7ffffffffffffff,
    Frob = tell_me(Baz)
    // non-constexpr function 'tell_me<long>' cannot be used in a constant expression
};

Notez que dans ce cas, T a été déduit comme étant long , mais après l'accolade fermante, il est supposé être Foo:

TranslationUnitDecl
`-EnumDecl <line:1:1, line:5:1> line:1:6 Foo
  |-EnumConstantDecl <line:2:5> col:5 Frob 'Foo'
  |-EnumConstantDecl <line:3:5> col:5 Bar 'Foo'
  `-EnumConstantDecl <line:4:5, col:11> col:5 Baz 'Foo'
    `-ImplicitCastExpr <col:11> 'unsigned long' <IntegralCast>
      `-IntegerLiteral <col:11> 'long' 576460752303423487

Si vous voulez que votre type d'énumération être signé avec Clang, vous devez le spécifier en utilisant la syntaxe : base_type , ou vous devez avoir un énumérateur négatif.

Je pense que la réponse à cet avertissement (certes peu intuitif) se trouve dans 7.6 Promotions intégrales [conv.prom]:

Une prvalue d'un type d'énumération non scopé dont le type sous-jacent n'est pas fixed (10.2) peut être converti en une valeur pr de la première des les types suivants qui peuvent représenter toutes les valeurs de l'énumération (c'est-à-dire les valeurs comprises entre b _min et b _max comme décrit en 10.2): int , unsigned int , long int , unsigned long int , long long int , ou unsigned long long int .

Par exemple, si votre type sous-jacent n'est pas fixe, et que vous utilisez un membre d'énumération dans une expression, il ne se convertit pas nécessairement en type sous-jacent de l'énumération. Il se convertit plutôt en le premier type de cette liste dans lequel tous les membres rentrent.

Ne me demandez pas pourquoi, la règle me semble folle.

Cette section continue en disant :

Une prvalue d'un type d'énumération non scopé dont le type sous-jacent est fixed (10.2) peut être converti en une valeur pr de son type sous-jacent.

C'est-à-dire si vous corrigez le type sous-jacent avec unsigned long :

EN_2 = 0x8000000000000000

alors l'avertissement disparaît.

Une autre façon de se débarrasser de l'avertissement (et laisser le type sous-jacent non fixé) est d'ajouter un membre qui nécessite un stockage unsigned long :

enum UEn : unsigned long
...

Là encore, l'avertissement s'en va.

Bonne question. J'ai beaucoup appris en y répondant.

Le libellé de la section 10.2p5 dit explicitement "... avant l'accolade fermante ..." suggère l'interprétation suivante. Le type d'un énumérateur dans la définition du type enum (avant l'accolade fermante) est choisi pour être un type entier suffisamment grand pour représenter sa valeur. Cette valeur peut ensuite être réutilisée dans la définition de la définition des énumérateurs suivants dans la même énumération. Lorsque l'accolade fermante de type enum est rencontrée, le compilateur choisit un type intégral suffisamment grand pour représenter toutes les valeurs de l'énumérateur. Après la définition du type enum, toutes les valeurs de l'énumérateur ont le même type (qui est le type enum) et partagent le type sous-jacent de l'énumération. Par exemple:

i
2E1
2E1
2E1

Ran avec clan5 et gcc8 et il renvoie:

#include <iostream>
#include <typeinfo>
#include <type_traits>

enum E1
{
  e1 = 0, // type of the initializer (int), value = 0
  e2 = e1 + 1U, // type of the initializer (unsigned = int + unsigned), value = 1U
  e3 = e1 - 1, // type of the initializer (int = int - int), value = -1
}; // range of values [-1, 1], underlying type is int

int main()
{
   std::cout << typeid(std::underlying_type<E1>::type).name() << '\n';
   std::cout << typeid(e1).name() << '\n';
   std::cout << typeid(e2).name() << '\n';
   std::cout << typeid(e3).name() << '\n';
}