Pourquoi écrire 1 000 000 000 comme 1000*1000*1000 en C ?

Question

Dans le code créé par Apple, il y a cette ligne :

CMTimeMakeWithSeconds( newDurationSeconds, 1000*1000*1000 )

Y a-t-il une raison d'exprimer 1,000,000,000 comme 1000*1000*1000 ?

Pourquoi pas 1000^3 d'ailleurs ?

Answer 1

L'une des raisons de déclarer les constantes de manière multiplicative est d'améliorer la lisibilité, sans affecter les performances d'exécution. Cela permet également d'indiquer que l'auteur a pensé au nombre d'une manière multiplicative.

Considérez ceci :

double memoryBytes = 1024 * 1024 * 1024;

C'est nettement mieux que :

double memoryBytes = 1073741824;

car ce dernier ne semble pas, à première vue, être la troisième puissance de 1024.

Comme l'a mentionné Amin Negm-Awad, la ^ est l'opérateur binaire XOR . De nombreux langages ne disposent pas d'un opérateur d'exponentiation intégré à la compilation, d'où la multiplication.

Answer 2

Il y a des raisons pas à utiliser 1000 * 1000 * 1000 .

Avec 16 bits int , 1000 * 1000 déborde. Ainsi, l'utilisation de 1000 * 1000 * 1000 réduit la portabilité.

Avec 32-bit int la première ligne de code suivante déborde.

long long Duration = 1000 * 1000 * 1000 * 1000;  // overflow
long long Duration = 1000000000000;  // no overflow, hard to read

Suggérer que la valeur du plomb corresponde au type de destination pour des raisons de lisibilité et de portabilité. y l'exactitude.

double Duration = 1000.0 * 1000 * 1000;
long long Duration = 1000LL * 1000 * 1000 * 1000;

On pourrait aussi utiliser simplement e pour les valeurs qui sont exactement représentables sous la forme d'un double . Bien entendu, cela conduit à savoir si double peut représenter exactement la valeur du nombre entier, ce qui pose problème pour les valeurs supérieures à 1e9 (voir DBL_EPSILON et DBL_DIG ).

long Duration = 1000000000;
// vs.
long Duration = 1e9;

Answer 3

Pourquoi pas 1000^3 ?

Le résultat de 1000^3 est de 1003. ^ est l'opérateur bit-XOR.

Même s'il ne s'agit pas de la question elle-même, j'apporte une précision. x^y fait pas sont toujours évalués à x+y comme dans l'exemple de l'auteur de la question. Il faut xer chaque bit. Dans le cas de l'exemple :

1111101000 (1000)
0000000011 (3)
1111101011 (1003)

Mais

1111101001 (1001)
0000000011 (3)
1111101010 (1002)

Answer 4

Pour plus de lisibilité.

En plaçant des virgules et des espaces entre les zéros ( 1 000 000 000 o 1,000,000,000 ) produirait une erreur de syntaxe, et le fait d'avoir 1000000000 dans le code ne permet pas de voir exactement le nombre de zéros.

1000*1000*1000 permet de voir qu'il s'agit de 10^9, car nos yeux peuvent traiter les morceaux plus facilement. De plus, il n'y a pas de coût d'exécution, car le compilateur le remplacera par la constante 1000000000 .

Answer 5

Pour plus de lisibilité. À titre de comparaison, Java prend en charge _ en nombre pour améliorer la lisibilité (proposé pour la première fois par Stephen Colebourne en tant qu'outil de gestion de l'information). Réponse à la PROPOSITION de Derek Foster : Littéraux binaires pour Project Coin/JSR 334) . On pourrait écrire 1_000_000_000 ici.

Dans un ordre à peu près chronologique, du soutien le plus ancien au plus récent :

• XPL : "(1)1111 1111" ( apparemment pas pour les valeurs décimales, seulement pour les chaînes de bits représentant des valeurs binaires, quartales, octales ou hexadécimales )
• PL/M : 1$000$000
• Ada : 1_000_000_000
• Perl : de même
• Ruby : de même
• Fantom (anciennement Fan) : de même
• Java 7 : de même
• Swift : (même ?)
• Python 3.6
• C++14 : 1'000'000'000

Il s'agit d'une fonctionnalité relativement nouvelle pour les langages qui réalisent qu'ils doivent la prendre en charge (et puis il y a Perl). Comme dans l'excellente réponse de chux@, 1000*1000... est une solution partielle, mais elle expose le programmeur à des bogues dus au débordement de la multiplication, même si le résultat final est un grand type.