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

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,000comme 1000*1000*1000?

Pourquoi pas 1000^3d'ailleurs?

L'une des raisons de déclarer des constantes de manière multiplicative est d'améliorer la lisibilité, tandis que les performances d'exécution ne sont pas affectées. Aussi, pour indiquer que l'écrivain pensait de manière multiplicative au nombre.

Considère ceci:

double memoryBytes = 1024 * 1024 * 1024;

C'est clairement mieux que:

double memoryBytes = 1073741824;

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

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

Pourquoi pas 1000^3?

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

Même s'il ne traite pas du Q lui-même, j'ajoute une précision. x^yn'évalue pas toujours x+ycomme dans l'exemple de l'interrogateur. Vous devez xor chaque bit. Dans le cas de l'exemple:

1111101000₂ (1000₁₀)
0000000011₂ (3₁₀)
1111101011₂ (1003₁₀)

Mais

1111101001₂ (1001₁₀)
0000000011₂ (3₁₀)
1111101010₂ (1002₁₀)

Il y a des raisons de ne pas utiliser 1000 * 1000 * 1000.

Avec 16 bits int, 1000 * 1000déborde. L'utilisation 1000 * 1000 * 1000réduit donc la portabilité.

Avec 32 bits 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 prospect correspond au type de destination pour la lisibilité, la portabilité et l' exactitude.

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

Il pourrait également être simple d'utiliser la enotation pour les valeurs qui sont exactement représentables sous forme de double. Bien sûr, cela conduit à savoir si doublepeut représenter exactement la valeur du nombre entier - ce qui est préoccupant avec des valeurs supérieures à 1e9. (Voir DBL_EPSILONet DBL_DIG).

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

Pour plus de lisibilité.

Placer des virgules et des espaces entre les zéros ( 1 000 000 000ou 1,000,000,000) produirait une erreur de syntaxe, et avoir 1000000000dans le code rend difficile de voir exactement combien de zéros il y a.

1000*1000*1000montre que c'est 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.

Pour plus de lisibilité. À titre de comparaison, Java prend _en charge les nombres pour améliorer la lisibilité (d'abord proposé par Stephen Colebourne en réponse à la PROPOSITION de Derek Foster: Binary Literals for Project Coin / JSR 334). On écrirait 1_000_000_000ici.

Dans l'ordre chronologique, du support le plus ancien au plus récent:

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

C'est une fonctionnalité relativement nouvelle pour les langages de se rendre compte qu'ils devraient prendre en charge (et puis il y a Perl). Comme dans l'excellente réponse de chux @, 1000*1000...est une solution partielle mais ouvre le programmeur aux bogues de débordement de la multiplication même si le résultat final est un grand type.

Cela pourrait être plus simple à lire et à obtenir des associations avec le 1,000,000,000formulaire.

D'un point de vue technique, je suppose qu'il n'y a aucune différence entre le nombre direct ou la multiplication. Le compilateur le générera de toute façon sous la forme d'un milliard constant.

Si vous parlez d'objectif-c, 1000^3cela ne fonctionnera pas car il n'y a pas une telle syntaxe pour pow (c'est xor). Au lieu de cela, la pow()fonction peut être utilisée. Mais dans ce cas, ce ne sera pas optimal, ce sera un appel de fonction d'exécution et non une constante générée par le compilateur.

Pour illustrer les raisons, considérez le programme de test suivant:

$ cat comma-expr.c && gcc -o comma-expr comma-expr.c && ./comma-expr
#include <stdio.h>

#define BILLION1 (1,000,000,000)
#define BILLION2 (1000^3)

int main()
{
        printf("%d, %d\n", BILLION1, BILLION2);
}
0, 1003
$

Une autre façon d'obtenir un effet similaire en C pour les nombres décimaux est d'utiliser la notation littérale à virgule flottante - tant qu'un double peut représenter le nombre souhaité sans aucune perte de précision.

IEEE 754 64 bits double peut représenter n'importe quel entier non négatif <= 2 ^ 53 sans problème. En règle générale, un double long (80 ou 128 bits) peut aller encore plus loin que cela. Les conversions seront effectuées au moment de la compilation, il n'y a donc pas de surcharge d'exécution et vous recevrez probablement des avertissements s'il y a une perte de précision inattendue et que vous avez un bon compilateur.

long lots_of_secs = 1e9;