Donc, la raison pour laquelle les types de données primitifs typedef:és est d'abstraire la représentation de bas niveau et de la rendre plus facile à comprendre (uint64_t au lieu de type long long, qui fait 8 octets).
Cependant, il y a uint_fast32_t qui a le même typedef que uint32_t. Utiliser la version "fast" rendra-t-il le programme plus rapide?
int peut être aussi petit que 16 bits sur certaines plateformes. Cela peut ne pas être suffisant pour votre application.uint32_t n'est pas garanti d'exister. C'est un typedef facultatif que l'implémentation doit fournir si elle dispose d'un type entier non signé de exactement 32 bits. Certains ont des bytes de 9 bits par exemple, donc ils n'ont pas de uint32_t.uint_fast32_t indique clairement votre intention : c'est un type d'au moins 32 bits qui offre les meilleures performances. uint_fast32_t peut en fait faire 64 bits de long. C'est à l'implémentation de décider.uint_least32_t dans le lot. Il désigne le type le plus petit qui fasse au moins 32 bits de long, donc il peut être plus petit que uint_fast32_t. C'est une alternative à uint32_t si ce dernier n'est pas supporté par la plateforme.... il y a
uint_fast32_tqui a le même typedef queuint32_t...
Ce que vous regardez n'est pas la norme. C'est une implémentation particulière (BlackBerry). Donc vous ne pouvez pas en déduire que uint_fast32_t est toujours le même que uint32_t.
Voir aussi :
Bonne réponse. Pour plus de précision, on pourrait peut-être souligner la différence avec uint_least32_t aussi, qui est la même que uint_fast32_t sauf qu'il favorise un stockage plus petit plutôt que la vitesse.
Pourquoi est-ce que l'entier le plus rapide qui soit d'au moins 32 bits en largeur est plus grand que 32 bits? J'ai toujours pensé que s'il y a moins de bits, le CPU doit travailler sur moins de bits, donc c'est plus rapide. Qu'est-ce que je rate ici?
@ShaneHsu: dire qu'un CPU 64 bits aura un additionneur de 64 bits, qui totalise des nombres de 64 bits en un cycle. Peu importe si tout ce que vous voulez faire est de travailler sur des nombres de 32 bits, cela ne sera pas plus rapide qu'un cycle. Maintenant, même si ce n'est pas le cas sur x86/amd64, les entiers de 32 bits peuvent ne pas être adressables. Dans un tel cas, travailler dessus nécessite des opérations supplémentaires pour extraire les 32 bits à partir, disons, d'unités alignées sur 64 bits. Voir aussi la question liée. La norme C++ est écrite de manière à pouvoir fonctionner sur une machine qui a des mots de 37 bits... donc aucun type de 32 bits là-bas.
La différence réside dans leur exactitude et leur disponibilité.
Le doc ici dit:
Type entier non signé d'une largeur de exactement 8, 16, 32 et 64 bits respectivement (fourni uniquement si l'implémentation supporte directement le type):
uint8_t uint16_t uint32_t uint64_t
Et
Type entier non signé le plus rapide d'une largeur d'au moins 8, 16, 32 et 64 bits respectivement
uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t
La différence est donc assez claire selon laquelle uint32_t est un type qui a exactement 32 bits, et une implémentation doit le fournir seulement si elle a un type avec exactement 32 bits, et ensuite elle peut définir ce type comme uint32_t. Cela signifie que uint32_t peut être ou ne pas être disponible.
En revanche, uint_fast32_t est un type qui a au moins 32 bits, ce qui signifie également qu'une implémentation peut définir uint32_t comme uint_fast32_t si elle fournit uint32_t. Si elle ne fournit pas uint32_t, alors uint_fast32_t pourrait être un typedef de n'importe quel type qui a au moins 32 bits.
Mais quelle est la raison qui fait par exemple que uint_fast32_t est plus rapide que uint32_t? Pourquoi est-il plus rapide?
@PravasiMeet : Tous les entiers ne sont pas accessibles de la même manière. Certains sont plus faciles d'accès que d'autres. Plus facile signifie moins de calcul, plus direct, ce qui se traduit par un accès plus rapide. Maintenant, uint32_t est exactement sur 32 bits sur tous les systèmes (s'il existe), ce qui pourrait ne pas être plus rapide par rapport à celui qui a, disons, 64 bits. uint_fast32_t d'autre part au moins 32 bits, pourrait même être sur 64 bits.
@Destructeur: Sur certains processeurs, si une variable est stockée dans un registre de taille supérieure, le compilateur peut devoir ajouter du code supplémentaire pour supprimer les bits supplémentaires. Par exemple, si uint16_t x; est stocké dans un registre de 32 bits sur l'ARM7-TDMI, le code x++; pourrait devoir être évalué comme x=((x+1)<<16)>>16);. Sur les compilateurs de cette plate-forme, uint_fast16_t serait très probablement défini comme synonyme de uint32_t pour éviter cela.
Lorsque vous #incluez inttypes.h dans votre programme, vous avez accès à différentes manières de représenter les entiers.
Le type uint_fast*_t définit simplement le type le plus rapide pour représenter un nombre donné de bits.
Pensez-y de cette façon : vous définissez une variable de type short et l'utilisez plusieurs fois dans le programme, ce qui est tout à fait valide. Cependant, le système sur lequel vous travaillez pourrait fonctionner plus rapidement avec des valeurs de type int. En définissant une variable de type uint_fast*t, l'ordinateur choisit simplement la représentation la plus efficace avec laquelle il peut travailler.
S'il n'y a pas de différence entre ces représentations, alors le système choisit celle qu'il veut et l'utilise de manière cohérente tout au long du processus.
Pourquoi inttypes.h et pas stdint.h? Il semble que inttypes.h ne contienne que diverses fioritures légèrement utiles, plus une inclusion de stdint.h?
@underscore_d Je connais la différence. Mais qui utilise stdio.h dans des programmes professionnels, peu importe le domaine d'application?
@Lundin Je n'ai aucune idée de qui ils sont, ou si ils existent ! Je pensais juste que cela pourrait être utile de fournir un lien pour expliquer ce que ce "contenu un peu utile" est ;-) Peut-être que cela aidera les gens à se rendre compte que vous avez raison et qu'ils n'en ont pas besoin.
Notez que la version rapide pourrait être plus grande que 32 bits. Alors que le fast int tiendra bien dans un registre et sera aligné et tout le reste : mais, il utilisera plus de mémoire. Si vous avez de grands tableaux de ceux-ci, votre programme sera plus lent en raison de plus de hits de mémoire cache et de bande passante.
Je ne pense pas que les processeurs modernes bénéficieront de fast_int32, car généralement l'extension du signe de 32 à 64 bits peut se produire lors de l'instruction de chargement et l'idée qu'il existe un format d'entier 'natif' plus rapide est dépassée.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Long long est peut-être pas de 8 octets, il est possible d'avoir un long long avec 1 octet (dans le cas où CHAR_BIT est d'au moins 64) ou avec 3738383 octets. aussi uint64_t peut être de 1, 2, 4 ou 8 octets, CHAR_BIT doit être de 64, 3, 16 ou 8 pour cela.