2009-11-28 9 views
31

Si int est synonyme de Int32 pourquoi neC# int, Int32 et énumérations

enum MyEnum : Int32 
{ 
    Value = 1 
} 

... pas compiler? Où

enum MyEnum : int 
{ 
    Value = 1 
} 

sera, même si planant le curseur sur le mot int affichera struct System.Int32?

+0

Quelle est l'erreur au moment de la compilation? – Donnie

+2

@Donnie: Type octet, sbyte, court, ushort, int, uint, long ou ulong attendu. Apparemment, une restriction dans .Net force l'utilisateur à utiliser uniquement des mots-clés au lieu des noms de classe dans une énumération. – Webleeuw

+0

Intéressant. J'ai appris quelque chose, yay! – Donnie

Répondre

29

Le type sous-jacent est en effet le même, mais le compilateur dépend du type à utiliser comme alias exact. C'est une erreur de compilation basée sur l'analyse. J'ai jeté un coup d'oeil à la spécification de grammaire C# et aux types sous-jacents qui y sont définis comme des jetons basés sur l'alias (par exemple, 'int', 'unit' ... etc.). L'analyseur attend des chaînes spécifiques de la règle de grammaire intégrale.

L'erreur est une erreur d'analyse même si les deux enum Enum : int signifient la même chose que enum Enum : Int32. Je ne connais pas la raison de forcer cette limite à l'étape d'analyse, mais je peux essayer de deviner: Puisque Int32 n'est pas un mot-clé, il peut se référer à quelque chose d'autre que la structure int réelle. Si l'analyseur doit connaître le type afin de construire différents AST pour chaque type de base, il ne peut pas dépendre du jeton qui n'est pas un mot-clé.

Même si la spécification C# définit le mot-clé int alias explicite System.Int32, il y a encore un problème pour obtenir ces informations sur le type explicite (Int32) lors de l'étape de l'analyse car elle nécessite beaucoup d'informations de contexte qui ne peut être déduit à cette étape.

+1

Voir aussi ce bug MS Connect où ils expliquent la justification pour ne pas changer le bahvior : http://connect.microsoft.com/VisualStudio/Commentaires/détails/557064/c-enum-declaration-only-accepte-value-type-alias-par exemple-short-int-long-à la place-de-net-valuetype-eg-system-int16-système- int32-system-int64 –

+0

@MichaelEdenfield que les liens Microsoft Connect n'est pas accessible. Pouvez-vous vérifier qu'il devrait être visible publiquement? Je reçois cette erreur 'Le contenu que vous avez demandé ne peut pas être trouvé ou vous n'avez pas la permission de l'afficher. Si vous pensez que vous avez atteint cette page par erreur, cliquez sur le lien Aide en haut de la page pour signaler le problème et inclure cet ID dans votre courrier électronique: e4c85df6-9343-4045-88d2-fc2d64bd01de ' –

+1

Non, Malheureusement, ils expirent connecter des liens après certains points. L'essentiel du bug était que "int" est un mot-clé et "Int32" est un type, et l'analyseur attend actuellement un "mot-clé" valide comme le type de base enum. Changer le comportement nécessite de changer l'ordre de la substitution mot-à-type par rapport aux étapes d'analyse enum et est un grand changement pour un minuscule, minuscule avantage, donc cela ne se produira probablement pas (à moins qu'il y ait d'autres changements connexes dans la même zone.) –

14

Une curiosité familière ... les Etats spécifications de langue (14.1):

Une déclaration enum peut déclarer explicitement un type sous-jacent de l'octet, sbyte, bref, ushort, int, uint, long ou ulong. Notez que char ne peut pas être utilisé comme type sous-jacent. Une déclaration enum qui ne déclare pas explicitement un type sous-jacent a un type sous-jacent de int.

Mais depuis int est généralement juste un alias pour System.Int32 il n'est pas déraisonnable de penser pourrait fonctionner soit ... mais en effet il ne fonctionne pas. Ce n'est généralement pas un gros problème, mais intrigant néanmoins.