Qu'est-ce que uint_fast32_t et pourquoi devrait-il être utilisé à la place de l'ordinaire int et uint32_t?

Donc, la raison pour typedef:ed types de données primitifs est à l'abstrait le faible niveau de représentation et de le rendre plus facile à comprendre (uint64_t au lieu de long long type, qui est de 8 octets).

Cependant, il est uint_fast32_t qui a le même typedef comme uint32_t. Le fait d'utiliser le "rapide" de la version de rendre le programme plus vite?

  • long long est peut-être pas 8 octets, il est possible d'avoir un long avec 1 octet (en cas CHAR_BIT est au moins 64) ou avec 3738383 octets. aussi un uint64_t peut être 1,2,4 ou 8 octets, CHAR_BIT doivent être 64, 3, 16 ou 8 pour que.
InformationsquelleAutor Amumu | 2011-12-14
  1. 115
    • int peut être aussi petit que 16 bits sur certaines plates-formes. Il peut ne pas être suffisante pour votre application.
    • uint32_t n'est pas garanti d'exister. C'est une option typedef que la mise en œuvre doit fournir ssi il a un type entier non signé de exactement 32-bits. Certains ont un 9 bits en octets par exemple, de sorte qu'ils n'ont pas uint32_t.
    • uint_fast32_t membres de votre intention clairement: c'est un type de au moins 32 bits qui est le meilleur de rendement, d'un point de vue. uint_fast32_t peut être en fait 64 bits. C'est à la mise en œuvre.

    ... il n'y a uint_fast32_t qui a le même typedef comme uint32_t ...

    Ce que vous regardez n'est pas la norme. C'est une mise en oeuvre particulière (BlackBerry). Donc vous ne pouvez pas déduire à partir de là que uint_fast32_t est toujours la même que uint32_t.

    Voir aussi:

    • La bonne réponse. Pour être complet, on pourrait peut-être remarquer la différence de uint_least32_t trop, ce qui est la même que uint_fast32_t sauf qu'il favorise les petits magasin plutôt que sur la rapidité.
    • Pourquoi le plus rapide entier qui est à moins de 32 bits de largeur de plus de 32 bits? J'ai toujours pensé que si il y a moins de bits, il y aura moins de bits CPU a travailler, donc plus rapide. Ce qui me manque ici?
    • dire d'un processeur 64 bits aura une version 64 bits de l'été, qui est la synthèse de 64 bits en un seul cycle. Ce n'est pas grave si tout ce que vous voulez faire est de travailler sur des nombres de 32 bits, il ne va pas être plus rapide qu'un cycle. Maintenant, bien qu'il n'est pas si sur x86/amd64, nombres entiers de 32 bits ne peut pas être en même adressable. Dans un tel cas de travail sur eux, il faut supplémentaires de la fpo pour extraire les 32 bits de 64 bits alignés unités. Voir aussi lié à la question. C++ standard est écrit de telle sorte qu'il puisse travailler sur une machine qui a 37 bits des mots... donc pas de 32 bits type là.
    InformationsquelleAutor ybungalobill
  2. 33

    La différence réside dans leur exacte-ness et de la disponibilité.

    La doc ici dit:

    type entier non signé avec la largeur de exactement 8, 16, 32 et 64 bits, respectivement (fourni uniquement si la mise en œuvre prend en charge directement le type): 

    uint8_t
uint16_t
uint32_t
uint64_t

    Et

    plus rapide unsigned unsigned integer avec la largeur de au moins 8, 16, 32 et 64 bits respectivement

    uint_fast8_t
uint_fast16_t
uint_fast32_t
uint_fast64_t

    Donc, la différence est à peu près clair que uint32_t est un type qui a exactement 32 bits, et une mise en œuvre devrait fournir seulement si elle est de type avec exactement 32 bits, et alors il peut typedef ce type uint32_t. Cela signifie, uint32_t peut ou peut ne pas être disponible.

    D'autre part, uint_fast32_t est un type qui a au moins 32 bits, ce qui signifie aussi, si une mise en œuvre peut typedef uint32_t comme uint_fast32_t si il fournit uint32_t. Si elle ne fournit pas uint32_t, puis uint_fast32_t pourrait être une définition de type de n'importe quel type qui a au moins 32 bits.

    • Mais quelle est la raison qui fait que par exemple uint_fast32_t plus vite que uint32_t? Pourquoi il est le plus rapide?
    • Pas tous les entiers accessibles de la même manière. Certains sont plus faciles d'accès que d'autres. Moyen plus facile moins de calcul, plus directe, ce qui entraîne un accès plus rapide. Maintenant uint32_t est exactement 32 bits sur tous les systèmes (si elle existe), ce qui pourrait ne pas être plus rapide par rapport à celui qui a, disons, 64-bit. uint_fast32_t sur l'autre main au moins 32 bits, peut-être même de 64 bits.
    • Sur certains processeurs, si une variable est stockée dans un registre qui est plus, le compilateur peut-être ajouter du code supplémentaire pour lop off supplémentaire bits. Par exemple, si uint16_t x; est stocké dans un 32 bits s'inscrire sur le ARM7TDMI, le code x++; peut-être besoin d'être évalué x=((x+1)<<16)>>16);. Sur des compilateurs pour cette plate-forme, uint_fast16_t serait le plus susceptible d'être définie comme synonyme de uint32_t pour l'éviter.
    • pourquoi [u]int_(fast|least)N_t pas aussi en option? Sûrement pas toutes les architectures sont requises par la Norme pour prendre en charge les types primitifs d'au moins 64 bits? Pourtant, le libellé de stdint.h implique qu'ils doivent. Il semble bizarre pour moi que nous avons à l'application que depuis 1999, quelques années avant l'informatique 64 bits est devenu mainstream - pour ne rien dire de la traîne (dans de nombreux cas, toujours d'actualité) des architectures embarquées. Cela semble comme une grande surveillance pour moi.
    • Une mise en œuvre ne correspondent pas à C99 ou C11, sauf si elle prend en charge un entier non signé de 64 bits type avec une représentation binaire. C'est un peu ironique compte tenu de la Norme de la volonté de se pencher vers l'arrière pour permettre à ceux-compléter et signer de magnitude formats, depuis toute plate-forme multi-précision arithmétique pouvez également appuyer deux-complément de mathématiques. Je connais un compilateur pour un de ceux-complément de plate-forme, et il avait signé un long long (qui je suppose n'auraient pas été stockés dans droit en binaire), mais pas non signé une.
    • Ouais, j'ai trouvé que peu de temps après. Il est bizarre exigence très ésotérique allocations ailleurs. Mais j'ai entendu des rumeurs que nous pourrions être sur le chemin exigeant complément de 2 (au moins superficiellement; je suppose que les plates-formes pourraient s'en inspirer si besoin)... ce qui serait au moins les rendre moins étrange, si pas nécessairement utile pour n'importe qui sur cette plateforme.
    • À mon humble avis, la Norme devrait se concentrer davantage sur la définition de la signification de code qui est accepté, qu'en imposant des choses que toutes les implémentations doivent accepter. Que serait "Une Règle de Programme" pour être remplacé par quelque chose de beaucoup plus utile-bien que pas de la mise en œuvre serait nécessaire pour traiter d'un programme particulier, on pourrait avoir une catégorie de programmes beaucoup plus grand que "Strictement Conforme", qui serait garanti pour s'exécuter correctement sur la mise en œuvre qui ne sont pas les rejeter.
    • Il n'y a pas de raison particulière, par exemple, que la Norme ne pouvait pas être applicable à un PIC12 mise en œuvre avec 16 octets de données de la RAM et de l'espace pour 256 instructions. Une telle mise en œuvre aurait besoin de rejeter un grand nombre de programmes, mais qui ne devrait pas l'empêcher de se comporter dans les régimes à la mode pour les programmes dont les besoins, il pourrait satisfaire.

    InformationsquelleAutor Nawaz
  3. 2

    Lorsque vous #include inttypes.h dans votre programme, vous aurez accès à tout un tas de façons différentes de représenter les entiers.

    La uint_fast*_t type 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 de l'utiliser plusieurs fois dans le programme, ce qui est totalement valide. Cependant, le système que vous êtes en train de travailler peuvent travailler plus rapidement avec des valeurs de type int. Par définition d'une variable de type uint_fast*t, l'ordinateur choisit simplement le plus efficace de la représentation qu'il peut fonctionner avec.

    Si il n'y a pas de différence entre ces représentations, le système choisit celui qu'il veut, et l'utilise de façon constante tout au long.

    • Pourquoi inttypes.h et pas stdint.h? Il semble que inttypes.h ne contient divers légèrement utile peluches, en plus d'une inclusion de stdint.h?
    • pour ref: stackoverflow.com/a/9162072/2757035
    • Je sais faire la différence. Mais qui utilise stdio.h dans les programmes professionnels, peu importe le domaine d'application?
    • Je n'ai aucune idée de qui ils sont, ou qu'ils existent! J'ai juste pensé qu'il pourrait être utile de fournir un lien d'élaborer sur ce que "modérément utile peluche" est 😉 peut-être que ça va aider les gens à réaliser que vous avez raison et qu'ils ne pas besoin d'elle.
    InformationsquelleAutor Harley Sugarman
  4. 0

    Noter que la version rapide pourrait être de plus de 32 bits. Alors que la vitesse de l'int s'intégrera parfaitement dans un registre et être aligné et assimilés: mais, il utilisera plus de mémoire. Si vous avez de grands tableaux de la ces votre programme sera plus lent en raison de plus de mémoire cache et de la bande passante.

    Je ne pense pas que les PROCESSEURS modernes bénéficieront de fast_int32, car généralement le signe d'étendre de 32 à 64 bits, peut se produire au cours de l'instruction de chargement et l'idée qu'il existe un "native" format de nombre entier qui est plus rapide est à l'ancienne.

    InformationsquelleAutor Gil Colgate