Pourquoi uint32_t serait-il préférable à uint_fast32_t?

Question

Il semble qu' uint32_t est beaucoup plus répandue qu' uint_fast32_t (je sais que c'est la preuve anecdotique). Cela semble contre-intuitif pour moi, si.

Presque toujours quand je vois une mise en œuvre utilisation uint32_t, tout ce qu'il veut vraiment, c'est un entier qui peut contenir des valeurs jusqu'à 4 294 967 295 (généralement beaucoup moins lié quelque part entre 65 535 et 4,294,967,295).

Ça fait bizarre d'utiliser uint32_t, comme le 'exactement 32 bits garantie n'est pas nécessaire, et le plus rapide disponible >= 32 bits garantie d' uint_fast32_t semblent être exactement la bonne idée. En outre, il est habituellement mis en œuvre, uint32_t n'est pas effectivement garanti d'exister.

Pourquoi, alors, serait - uint32_t à privilégier? Est-il tout simplement de mieux en mieux connue ou il y a des avantages techniques par rapport à l'autre?

Answer 1

uint32_t est garanti pour ont presque les mêmes propriétés sur toute plate-forme qui prend en charge.¹

uint_fast32_t a très peu de garanties sur la façon dont il se comporte sur les différents systèmes en comparaison.

Si vous passez à une plate-forme où uint_fast32_t a une taille différente, l'ensemble du code qui utilise uint_fast32_t doit être testé et validé. Tout la stabilité hypothèses vont être hors de la fenêtre. L'ensemble du système est en train de travailler différemment.

Lors de l'écriture de votre code, vous n'avez même pas accès à un uint_fast32_t système qui n'est pas de 32 bits.

uint32_t ne fonctionne pas différemment (voir note de bas de page).

L'exactitude est plus importante que la vitesse. Prématuré exactitude est donc un meilleur plan que de l'optimisation prématurée.

Dans l'événement que j'étais à l'écriture de code pour les systèmes où la uint_fast32_t était de 64 bits ou plus, je pourrais tester mon code pour les deux cas et l'utiliser. Sauf à la fois l'occasion et le besoin, c'est un mauvais plan.

Enfin, uint_fast32_t lorsque vous stockez elle, pour toute longueur de temps ou le nombre de cas peut être plus lent que l' uint32 simplement dû à la taille de la mémoire cache les problèmes de mémoire et de bande passante. Aujourd'hui les ordinateurs sont le plus souvent liés à la mémoire qu'en CPU, et uint_fast32_t pourrait être plus rapide dans l'isolement, mais pas après vous compte pour la surcharge de la mémoire.

---

¹ Comme @chux l'a fait remarquer dans un commentaire, si unsigned est plus grand que uint32_t, l'arithmétique sur uint32_t passe par l'habitude entier promotions, et si non, il reste sous la forme d' uint32_t. Cela peut provoquer des bugs. Rien n'est jamais parfait.

Answer 2

Pourquoi beaucoup de gens utilisent uint32_t plutôt que d' uint32_fast_t?

Remarque: la Mal nommée uint32_fast_t devrait être uint_fast32_t.

uint32_t a un resserrement de la spécification de uint_fast32_t et donc pour la cohérence des fonctionnalités.

---

uint32_t pros:

• Divers algorithmes de spécifier ce type. OMI - le meilleur de raison de les utiliser.
• Largeur exacte et la gamme connue.
• Des tableaux de ce type n'encourent aucune des déchets.
• unsigned integer maths avec son débordement est de plus en plus prévisible.
• Les plus proches en distance et en mathématiques des autres langues " 32-bit types.
• Jamais rembourré.

uint32_t contre:

• Pas toujours disponible (mais c'est rare en 2018).
  E. g.: Les plates-formes dépourvues de 8/16/32 bits entiers (9/18/36bits, autres).
  E. g.: Les plates-formes à l'aide de non-complément de 2. vieux 2200

uint_fast32_t pros:

• Toujours disponible.
  Ce toujours permettre à toutes les plates-formes, anciens et nouveaux, à utiliser rapide/minimum types.
• "Le plus rapide" type de support 32 bits de large.

uint_fast32_t contre:

• La gamme est très peu connu. Exemple, il pourrait être une version 64 bits de type.
• Des tableaux de ce type peut être gourmande en mémoire.
• Toutes les réponses (moi aussi au début), le post et les commentaires utilisé le mauvais nom uint32_fast_t. Ressemble beaucoup n'ont pas besoin et de l'utilisation de ce type. Nous n'avons même pas utiliser le bon nom!
• Rembourrage possible (rare).
• Dans certains cas, le "plus rapide" type peut vraiment être un autre type. Donc, uint_fast32_t n'est qu'une 1ère approximation d'ordre.

En fin de compte, ce qui est mieux dépend du codage de l'objectif. Sauf codant pour la très grande portabilité ou certaines nichées la performance de la fonction, utilisez uint32_t.

---

Il y a un autre problème lors de l'utilisation de ces types qui entre en jeu: leur rang par rapport à l' int/unsigned

Vraisemblablement uint_fastN_t serait au moins le grade de unsigned. Ce n'est pas précisé, mais une certaine et vérifiable condition.

Ainsi, uintN_t est plus probable qu' uint_fastN_t plus étroite de l' unsigned. Cela signifie que le code qui utilise uintN_t mathématiques est plus probable que l'objet en entier promotions que uint_fastN_t lorsque relatives à la portabilité.

Avec cette préoccupation: l'avantage de la portabilité uint_fastN_t avec la sélection des opérations mathématiques.

---

Remarque: environ int32_t plutôt que d' int_fast32_t: À de rares machines, INT_FAST32_MIN peut être -2,147,483,647 et pas -2,147,483,648. Le point le plus important: (u)intN_t types sont bien spécifiés et conduire à un code portable.

Answer 3

Pourquoi beaucoup de gens utilisent uint32_t plutôt que d' uint32_fast_t?

Réponse idiote:

• Il n'y a pas de type standard, uint32_fast_t, l'orthographe correcte est uint_fast32_t.

Réponse pratique:

• Beaucoup de gens utilisent réellement uint32_t ou int32_t de leur sémantique précise, exactement 32 bits non signé enrouler autour de l'arithmétique (uint32_t) ou 2 en complément de la représentation (int32_t). L' xxx_fast32_t types peuvent être plus grandes et donc inadaptée à la boutique pour les fichiers binaires, les utiliser dans les paniers des tableaux et des structures, ou de l'envoyer sur un réseau. En outre, ils peuvent même ne pas être plus rapide.

Pragmatique en réponse:

• Beaucoup de gens ne savent pas (ou n'ont tout simplement pas de soins) à propos de uint_fast32_t, comme l'a démontré dans les commentaires et les réponses, et sans doute supposer plain unsigned int à avoir la même sémantique, bien que de nombreuses architectures actuelles ont encore 16 bits ints et de quelques rares Musée des échantillons ont d'autres étranges int taille inférieure à 32.

UX réponse:

• Bien que peut-être plus rapidement qu' uint32_t, uint_fast32_t est plus lent à utiliser: il prend plus de temps, en particulier en comptabilité pour la recherche d'orthographe et de la sémantique dans le C de la documentation ;-)

L'élégance des questions, (évidemment opinion fondée):

• uint32_t semble assez mauvais que beaucoup de programmeurs préfèrent définir leur propre u32 ou uint32 type de... de ce point De vue, uint_fast32_t semble maladroit au-delà de la réparation. Pas de surprise, il est assis sur le banc avec ses amis uint_least32_t , par exemple.

Answer 4

Une des raisons est qu' unsigned int est déjà "le plus rapide", sans la nécessité pour toutes les typedefs ou la nécessité d'inclure quelque chose. Donc, si vous en avez besoin rapidement, il suffit d'utiliser la fondamentale int ou unsigned int type.
Bien que cette norme ne garantit pas explicitement qu'il est plus rapide, il indirectement le fait en disant "Plaine ints ont la taille naturelle suggéré par l'architecture de l'environnement d'exécution" dans 3.9.1. En d'autres termes, int (ou de sa non signé de contrepartie) est ce que le processeur est plus à l'aise.

Bien sûr, maintenant, vous ne savez pas quelle taille unsigned int peut-être. Vous ne savez que c'est au moins aussi grand que short (et je crois me souvenir qu' short doit être d'au moins 16 bits, bien que je ne la retrouve pas que dans la norme maintenant!). Habituellement, il est tout simplement tout simplement de 4 octets, mais il pourrait en théorie être plus grand, ou dans des cas extrêmes, même la plus petite (bien que je n'ai personnellement jamais rencontré une architecture où cela a été le cas, même pas sur 8 bits des ordinateurs dans les années 1980... peut-être que certains microcontrôleurs, qui sait s'avère que je souffre de démence, int a été très clairement de 16 bits puis).

La norme C++ ne prend pas la peine de préciser quel est le <cstdint> types sont ou ce qu'ils ont de la garantie, il mentionne simplement "comme en C".

uint32_t, conformément à la norme C, garantit que vous obtenez exactement 32 bits. Pas quelque chose de différent, ni moins et pas de rembourrage bits. Parfois, c'est exactement ce dont vous avez besoin, et il est donc très précieux.

uint_least32_t garanties que quelle que soit la taille de l'est, il ne peut pas être inférieur à 32 bits (mais il pourrait très bien être plus grande). Parfois, mais beaucoup plus rarement qu'une exacte largeur ou "don't care", c'est ce que vous voulez.

Enfin, uint_fast32_t est un peu superflue à mon avis, à l'exception de la documentation d'intention fins. Le C standard unis "désigne un type entier, qui est généralement la plus rapide" (notez le mot "généralement") et mentionne explicitement qu'il ne doit pas être le plus rapide pour tous les usages. En d'autres termes, uint_fast32_t est à peu près le même que uint_least32_t, ce qui est généralement plus rapide aussi, qu'aucune garantie n'est donnée (mais aucune garantie de toute façon).

Puisque la plupart du temps, vous ne se soucient pas de la taille exacte ou vous voulez exactement 32 (ou 64, parfois 16) bits, et depuis le "don't care" unsigned int type est le plus rapide de toute façon, c'est ce qui explique pourquoi uint_fast32_t n'est pas fréquemment utilisé.

Answer 5

Je n'ai pas vu la preuve qu' uint32_t être utilisé pour sa gamme. Au lieu de cela, la plupart du temps que j'ai vus uint32_t est utilisé, c'est de tenir exactement 4 octets de données dans différents algorithmes, avec des garanties de wraparound et changement sémantique!

Il y a aussi d'autres raisons d'utiliser uint32_t au lieu de uint_fast32_t: Souvent, c'est qu'il fournira ABI stable. En outre, l'utilisation de la mémoire peut être connu avec précision. Cette très décalages quelle que soit la vitesse, le gain serait de uint_fast32_t, chaque fois que ce type serait distincte de celle de uint32_t.

Pour les valeurs < 65536, il existe déjà une pratique de type, il est appelé unsigned int (unsigned short est nécessaire d'avoir au moins cette plage, mais unsigned int est de la patrie, de la taille de mot) Pour les valeurs < 4294967296, il y a un autre appelé unsigned long.

---

Et enfin, les gens de ne pas utiliser uint_fast32_t parce que c'est fâcheusement long à taper et facile à une faute de frappe :D