3- par expérience, sauf besoin spécifiques, il faut se passer un maximum des types uintXX_t.
Je serais intéressé de savoir quels problèmes tu as eu avec ces types? Mis à part qu'ils peuvent ne pas être définis sur une archi ( contrairement aux types least et fast ), je ne vois pas de problème particulier?
En fait, j'ai l'impression que c'est même le contraire, dans un code:
écrit par des gens ne connaissant pas stdint et donc les macros maxi/mini pour les int/char/short/long : on ne m'a jamais parlé de stdint.h à l'école, c'était pourtant en 2006, ça existait... à la place de ça, les profs nous disaient qu'un int c'est toujours 32 bits, la même taille qu'un long ( Chance pour moi: j'avais appris en autodidacte sur du C 16bits, avec un compilo différent, et un peu pratiqué du 32bits avec ce même compilo, du coups j'ai tilté qu'il est plus sûr d'utiliser short et long plutôt qu'int, moins de variations sur les plate-formes que je connaissait à l'époque ). Et là, je parle d'un étudiant. Un vieux roublard des intel x86 aura lui, potentiellement acquis des habitudes pas clean, et aurait pu utiliser les mêmes trucs crades de comparer à des constantes numériques faites main. Par exemple, je ne serais pas surpris de voir ce type de choses dans le moteur de certains vieux quake ou de duke nukem.
écrit avant 1999: stdint.h, c'est le standard C99
écrit pour être compatible avec du C++ pré 2011: stdint.h n'est standard que depuis C++11
voir des constantes numériques faites main pour tester la valeur maxi lors d'une itération n'est pas rare. Et bien sûr, la portabilité prend un sacré coup dans la gueule ( voire même la stabilité s'il s'est planté, mais bon... ). Alors que des types XintYY_t, quitte à ce qu'ils soient redéfinis ( comme le fait la SDL 1.2, par exemple ) peuvent être comparés au premier coup d'œil à la valeur testée: 0xFFFF et 0x7FFF pour les signés, -1 pour les non signés ( ça au moins ça marche toujours... je crois? ).
Ce que je veux dire, c'est qu'au moins, avec un uint16_t les valeurs mini/maxi/maxi non signé numériques sont fiables ( même si je suis d'accord qu'il faut éviter, mais les codes sources n'ont pas tous la possibilité d'être compilé avec des compilos respectant C99 ( 15 ans c'est jeune comparé au langage C ).
[^] # Re: Non garantie du compilateur
Posté par freem . En réponse au message Les espacements que mettent les compilateurs C dans les structures sont ils toujours les mêmes ?. Évalué à 1.
Je serais intéressé de savoir quels problèmes tu as eu avec ces types? Mis à part qu'ils peuvent ne pas être définis sur une archi ( contrairement aux types least et fast ), je ne vois pas de problème particulier?
En fait, j'ai l'impression que c'est même le contraire, dans un code:
voir des constantes numériques faites main pour tester la valeur maxi lors d'une itération n'est pas rare. Et bien sûr, la portabilité prend un sacré coup dans la gueule ( voire même la stabilité s'il s'est planté, mais bon... ). Alors que des types XintYY_t, quitte à ce qu'ils soient redéfinis ( comme le fait la SDL 1.2, par exemple ) peuvent être comparés au premier coup d'œil à la valeur testée: 0xFFFF et 0x7FFF pour les signés, -1 pour les non signés ( ça au moins ça marche toujours... je crois? ).
Ce que je veux dire, c'est qu'au moins, avec un uint16_t les valeurs mini/maxi/maxi non signé numériques sont fiables ( même si je suis d'accord qu'il faut éviter, mais les codes sources n'ont pas tous la possibilité d'être compilé avec des compilos respectant C99 ( 15 ans c'est jeune comparé au langage C ).