Le programme suivant ne compilera pas:
Byte[] y = new Byte[3] { 50, 50, 50 };
6 Réponses :
Le compilateur traitera simplement la constante comme si vous écrivez le numéro là-bas, mais il doit y avoir une conversion implicite.
Dans votre troisième extrait, ces trois 50 sont tous system.int32 . Survolez votre souris dessus et lisez l'info-bulle dans Visual Studio. Pourquoi l'erreur de compilateur n'est-elle pas ici? Parce que le compilateur connaît la valeur au moment de la compilation et sait qu'il ira à l'intérieur d'un octet .
En gros, c'est que la différence est que lorsque le compilateur connaît la valeur au moment de la compilation, la mise en forme est autorisée est la valeur du type de numéro plus grand se trouve dans la plage autorisée pour le type de numéro de plus petit. Si le compilateur ne sait pas si tel est le cas ou non, il n'est pas autorisé à moins que vous n'utilisiez pas de coulée explicite pour vous assurer que ce sera dans cette plage lorsque le programme s'exécute.
Même si, nous savons que la valeur de X est peu susceptible de changer entre sa déclaration et son utilisation, sachant que cela ne changera pas nécessite une analyse complexe que le compilateur ne tente pas (et sera réellement impossible à toujours obtenir correct). Si une variable n'est pas constituée, le compilateur ne fait aucune inférence sur sa valeur réelle.
La valeur non constante peut être trop grande pour un octet, alors que la valeur constante est constante et garantie d'être inférieure au seuil dans ce cas.
La réponse est la suivante: en raison de la const devient un littéral par routines de préprocesseur et est interprété comme «code», tandis qu'une variable ne fonctionne pas.
Les constantes sont «cuites au four» au moment de la compilation.
Une conséquence remarquable de la compilation des constantes est que si vous compilez contre un assemblage, il utilisera les valeurs constantes au moment de la compilation. Si vous liez plus tard une version différente de l'Assemblée au moment de l'exécution, il utilisera les constantes d'origine, même si elles ont changé dans la nouvelle version de l'Assemblée. Cela s'applique également aux constantes d'Enum, en particulier. La morale de l'histoire est que les valeurs constantes (publiques) devraient vraiment être constantes; S'il y a une possibilité d'un changement significatif survenant, utilisez plutôt un champ de lecture statique.
Je vous réfère à la section 6.1.9 de la spécification C # 4, qui indique:
Une expression constante de type INT peut être convertie en Sbyte, octet, courte, Uste, UINT ou Ulong, à condition que la valeur de l'expression constante soit dans la plage du type de destination.
Votre question était:
Le compilateur crée-t-il une version "octet" de mon const à la volée ou le compilète-t-il comme si j'avais mis en phase explicite, car il juge la valeur constante "sûre" pour un octet?
Je ne comprends pas la différence entre ces deux choses; ils sonnent comme la même chose pour moi.
Ah, cette citation de la spécification était exactement ce que je cherchais. Merci!
Les valeurs
const sont substituées.Essayez avec
Public const int x = 350;Liée: Stackoverflow.com/questions/9008637/...