Question

J'ai toujours utilisé TypeDEF dans une programmation intégrée pour éviter les erreurs courantes:

int8_t - entier signé à 8 bits
int16_t - entier signé 16 bits
int32_t - entier signé 32 bits
uint8_t - entier non signé 8 bits
uint16_t - entier 16 bits non signé
uint32_t - entier non signé 32 bits

La récente muse intégrée (numéro 177, pas encore sur le site Web) m'a présenté l'idée qu'il est utile d'avoir des typedes spécifiques aux performances. Cette norme suggère d'avoir des typèdes qui indiquent que vous voulez le type le plus rapide qui a une taille minimale.

Par exemple, on pourrait déclarer une variable en utilisant int_fast16_t, mais il serait en fait implémenté comme un int32_t sur un processeur 32 bits, ou int64_t Sur un processeur 64 bits, car ceux-ci seraient les types les plus rapides d'au moins 16 bits sur ces plates-formes. Sur un processeur 8 bits, ce serait int16_t bits pour répondre à l'exigence de taille minimale.

N'ayant jamais vu cette utilisation avant de vouloir savoir

  • Avez-vous vu cela dans des projets, intégrés ou autrement?
  • Des raisons possibles pour éviter ce type d'optimisation dans les typedes?
Était-ce utile?

La solution

Par exemple, on peut déclarer une variable en utilisant INT_FAST16_T, mais elle serait en fait implémentée en tant qu'INT32_T sur un processeur 32 bits, ou INT64_T sur un processeur 64 bits, car ceux-ci seraient les types les plus rapides d'au moins 16 bits sur ces plates-formes

C'est à quoi sert Int, n'est-ce pas? Êtes-vous susceptible de rencontrer un processeur 8 bits de sitôt, où cela ne suffirait pas?

Combien de données uniques pouvez-vous rappelles toi?

Cela offre-t-il tellement d'avantages supplémentaires qu'il vaut la peine de doubler efficacement le nombre de types à considérer chaque fois que je crée une variable entière simple?

J'ai du mal à imaginer la possibilité qu'il puisse être utilisé de manière cohérente.

Quelqu'un va écrire une fonction qui renvoie un int16fast_t, puis quelqu'un d'autre va venir et stocker cette variable dans un int16_t.

Ce qui signifie que dans le cas obscur où le vite Les variantes sont en fait bénéfiques, elles peuvent modifier le comportement de votre code. Cela peut même provoquer des erreurs ou des avertissements du compilateur.

Autres conseils

Vérifier stdint.h de C99.

La principale raison pour laquelle j'éviterais ce type de type est qu'elle permet au type de mentir à l'utilisateur. Prenez int16_t vs int_fast16_t. Les deux noms de type codent la taille de la valeur dans le nom. Ce n'est pas une pratique rare en C / C ++. J'utilise personnellement la taille spécifique des types pour éviter la confusion pour moi-même et les autres qui lisent mon code. Une grande partie de notre code doit fonctionner sur les plates-formes 32 et 64 bits et de nombreuses personnes ne connaissent pas les différentes règles de dimensionnement entre les plateformes. Des types comme int32_t éliminent l'ambiguïté.

Si je n'avais pas lu le 4ème paragraphe de votre question et que je viens de voir le nom de type, j'aurais supposé que c'était une manière spécifique au scénario d'avoir une valeur rapide de 16 bits. Et j'aurais évidemment eu tort :(. Pour moi, cela violerait la règle de la programmation "Ne surprendre des gens".

Peut-être que s'il avait un autre verbe, lettre, acronyme dans le nom, il serait moins susceptible de confondre les utilisateurs. Peut-être int_fast16min_t?

Quand je regarde int_fast16_t, et je ne suis pas sûr de la largeur native du processeur dans lequel il fonctionnera, il peut compliquer les choses, par exemple le ~ opérateur.

int_fast16_t i = 10;
int_16_t j = 10;

if (~i != ~j) {
  // scary !!!
}

D'une manière ou d'une autre, je voudrais utiliser volontairement 32 bits ou 64 bits en fonction de la largeur native du processeur.

Je ne suis en fait pas un fan de ce genre de chose.

Je l'ai vu à plusieurs reprises (en fait, nous avons même ces typèdes dans mon lieu d'emploi actuel) ... Pour la plupart, je doute de leur véritable utilité ... cela me frappe comme un changement pour les changements. . (Et oui, je sais que les tailles de certains des Ins construites peuvent varier) ...

J'utilise généralement size_t, il se trouve que c'est la taille d'adresse la plus rapide, une tradition que j'ai ramassée dans l'intégration. Et cela n'a jamais causé de problèmes ou de confusion dans les cercles intégrés, mais cela a en fait commencé à me causer des problèmes lorsque j'ai commencé à travailler sur des systèmes 64 bits.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top