Pourquoi ou pourquoi ne pas utiliser 'UL' pour spécifier non signé longtemps?

Question

ulong foo = 0; 
ulong bar = 0UL;//this seems redundant and unnecessary. but I see it a lot. 

Je vois aussi en référence au premier élément de tableaux une bonne quantité

blah = arr[0UL];//this seems silly since I don't expect the compiler to magically 
       //turn '0' into a signed value 

Quelqu'un peut-il donner un aperçu de la raison pour laquelle j'ai besoin « UL » tout au long de préciser expressément que c'est un unsigned long?

Answer 1

void f(unsigned int x) 
{ 
// 
} 

void f(int x) 
{ 
// 
} 
... 
f(3); // f(int x) 
f(3u); // f(unsigned int x) 

Il est juste un autre outil en C++; Si vous n'en avez pas besoin, ne l'utilisez pas!

Answer 2

Vous n'en avez normalement pas besoin, et n'importe quel éditeur tolérable aura assez d'aide pour garder les choses au point. Cependant, les endroits où je l'utilise en C# sont (et vous verrez ce en C++):

• appelle une méthode générique (modèle en C++), où les types de paramètres sont implicites et que vous voulez faire et appelez celui avec un type unsigned long. Cela arrive assez souvent, y compris celui-ci récemment:
  Tuple<ulong, ulong> = Tuple.Create(someUlongVariable, 0UL);
  où sans le UL il renvoie Tuple<ulong, int> et ne compilera pas.
• Déclarations implicites de variables utilisant le mot-clé var en C# ou le mot-clé auto venant en C++. Ceci est moins commun pour moi car je n'utilise que var pour raccourcir des déclarations très longues, et ulong est le contraire.

Answer 3

Certains compilateurs peuvent émettre un avertissement je suppose.
L'auteur pourrait faire cela pour s'assurer que le code n'a pas d'avertissement?

Answer 4

Dans les exemples que vous fournissez, il n'est pas nécessaire. Mais les suffixes sont souvent utilisés dans les expressions pour éviter la perte de précision. Par exemple:

unsigned long x = 5UL * ... 

Vous pouvez obtenir une réponse différente si vous l'avez laissé le suffixe UL, par exemple si votre système avait ints et désire ardemment 32 bits 16 bits.

Voici un autre exemple inspiré par les commentaires de Richard Corden:

unsigned long x = 1UL << 17; 

Encore une fois, vous obtiendrez une réponse différente si vous aviez 16 ou 32 bits entiers si vous avez quitté le suffixe off.

Le même type de problème s'appliquera avec 32 contre 64 bits ints et le mélange long et long long dans les expressions.

Answer 5

Lorsque vous vous sentez obligé d'écrire le type de constante (même pas absolument nécessaire) vous assurez:

1. que vous considérez comme toujours comment le compilateur se traduira par cette constante en bits
2. Qui a jamais lit votre code saura toujours comment vous avez pensé que la constante ressemble et que vous l'avez pris en considération (même vous, quand vous re-scannez le code)
3. Vous ne perdez pas de temps si vous avez besoin d'écrire le 'U'/'UL' ou n'ont pas besoin de l'écrire

également, plusieurs normes de développement de logiciels tels que MISRA vous demandent de mentionner le type de constante, peu importe ce que (au moins écrire « U » si non signé)

dans d'autres termes, il est considéré par certains comme une bonne pratique de écrire le type de constante car dans le pire des cas vous l'ignorez et au mieux vous évitez les bugs, évitez que des compilateurs différents n'abordent votre code différemment et améliorent la lisibilité du code

Answer 6

Désolé, je réalise que c'est une question assez ancienne , mais je l'utilise beaucoup en code C++ 11 ...

ul, d, f sont tous utiles pour initialiser auto variables à votre type prévu, par ex.

auto my_u_long = 0ul; 
auto my_float = 0f; 
auto my_double = 0d; 

Commander la référence cpp sur les littéraux numériques: http://www.cplusplus.com/doc/tutorial/constants/