Discussion :

[kripteks]

Salut à tous.
Pour des valeurs faible, vaut-il mieux utiliser short ou int.

Short semble avantageux (moins d'octet), mais généralement on utilise int (ex: sur les tutoriels et bout de code sur internet).

Cela est dû à la mémoire haut de ces derniers époques, mais vaut-il mieux de prendre l'habitude à utiliser un short ?

[darkwall_37]

Salut,

Si tu es certains que l'intervalle de valeurs que prend ta variable est celle définit par un short, oui il sera inutile de la déclarer en tant que int.
En effet, on se pose de moins en moins la question depuis la que la RAM disponible aujourd'hui est giga-tesque.
Cela n'est pas une raison en effet pour ne pas se poser la question. Certaines applications peuvent paraître gourmande pour ce qu'elles ont à faire, à juste titre, cela illustre ton propos.

Cordialement.

[Kannagi]

Cela depent si tu fait ds int dans tes fonction c'est pas très grave et tu y gagnerai pas beaucoup en mémoire en les remplacent par des short, par contre si tu fait un malloc de int et que tu peut le mettre en short , et si ton programme possède beaucoup ce genre de données , tu peux effectivement réduire de beaucoup en mémoire ton programme.

[droggo]

Loa,

Avec un bémol : les processeurs modernes n'aiment pas beaucoup mixer les calculs avec des variables de tailles différentes.

Donc, à moins d'avoir une très grosse quantité de ces variables, utiliser des int.

[Sve@r]

Salut
short ou int (ou même char pourquoi pas, c'est toujours un nombre) importe généralement peu. En revanche, pense plutôt à mettre unsigned pour un nombre dont tu es certain qu'il sera toujours positif (surtout pour les nombres dont les bits servent d'indicateurs booléens qu'on positionne avec des | => style S_IRUSR|S_IWUSR|S_IXUSR).
Parce qu'il existe un mécanisme assez gourmand pour les signed : l'extension du bit de signe.

Imagine que par le jeu des manipulations de bits, ton char tombe à 100000001 (soit -143). Si jamais ensuite tu l'associes avec un short dans une expression (une comparaison, un calcul), le premier 1 sera étendu sur toute la longueur du short afin de conserver le signe et la valeur. Ce qui donnera 1111111110000001 (soit toujours -143).
Cette opération (répétée dans chaque expression) sera évitée si ta variable est unsigned.

[Neckara]

Bonjour,

Personnellement, je déconseillerais l'utilisation de short, int et consort.

En revanche je favoriserais (u)intXX_t et (u)int_fastXX_t.

Avec (u)intXX_t, tu peux choisir la taille de tes données et donc choisir la "plage de valeur" que ta variable peut prendre. Comme on connaîtra exactement sa taille, on pourra jouer là-dessus.
Avec (u)int_fastXX_t tu peux choisir une taille minimale pour tes données et avoir une taille réelle qui sera la plus rapide possible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
typedef uint16_t key_t;
typedef uint_fast16_t key_fast_t;

Ainsi tu pourras proposer deux types :

• key_t qui sera utilisé de "base" et si l'utilisateur a des contraintes de mémoire (grands tableaux) ;
• key_fast_t qui sera utilisée si l'utilisateur a de très grandes contraintes en vitesse d'exécution (section de code très critique).

Le problème avec les types comme int, c'est que tu as une taille réelle qui peut varier et une taille minimale qui est très souvent peu connue par ses utilisateurs. On risque donc de se retrouver avec des codes peu portables et avec des bugs à corriger si on change d'architecture.


Après conseiller int plutôt que short est ridicule. Certes int devrait être légèrement plus rapide mais c'est négligeable, c'est de la micro-optimisation inutile.
Si on a vraiment des contraintes de temps, on utilisera un (u)int_fastXX_t.
Sans compter qu'avant de rentrer dans la micro-optimisation, on va déjà chercher à réduire la complexité de l'algorithme, etc.



Ensuite, pour les contraintes mémoire, c'est la même choses. Si on a de réelles contraintes mémoires, on utilisera uintXX_t où on connaîtra exactement la taille du type plutôt que de choisir un short qui fera "au minimum 2 octets" sans savoir s'il en fait 3 ou 4 voir plus.
Et là encore, on va d'abord essayer de réduire la complexité mémoire de l'algorithme.



En conclusion, si tu as de réelles contraintes, laisse tomber les short ou les int et utilise le type le plus adapté à ta contrainte (vitesse ? mémoire ? taille minimale du type ?).
Mais à ton niveau, tu n'as pas de telles contraintes, tu peux choisir le type que tu préfères cela n'a pas trop d'importance. En revanche, afin de produire un code clair et portable, je te conseille d'utiliser les (u)intXX_t.

[kripteks]

Waw, dans chaque message j'ai trouver des choses hyper intéressent et important.

J’aime bien ce genre d'info, même débutant, ce genre d'infos sont très éducatif même si dans l'état actuel je suis pas presser pour de l'optimisation.


Merci à tous.

[Obsidian]

Bonjour,

Personnellement, je déconseillerais l'utilisation de short, int et consort.

En revanche je favoriserais (u)intXX_t et (u)int_fastXX_t.

Ce n'est pas un bon conseil : int, short et consors sont des mots-clés réservés du C et sont donc disponibles sur tous les compilateurs, même si leur largeur peut varier d'une architecture à l'autre. (u)intXX et ses variantes sont ensuite définis à partir de ses types par un #include écrit pour l'architecture cible. Leur largeur est alors fixe mais leur disponibilité n'est plus garantie. S'il n'est pas possible d'implémenter un uint8_t sur une architecture donnée, ton programme ne compilera pas du tout. Outre ce fait, imposer un format aussi strict au compilateur risque de dégrader inutilement les performances du code objet produit.

Ce n'est donc à utiliser que si c'est nécessaire, c'est-à-dire soit pour du très bas niveau (embarqué et pilotes de périphériques hardware), soit pour l'exportation de données (trames réseau et formats de fichiers).

[mith06]

S'il n'est pas possible d'implémenter un uint8_t sur une architecture donnée

Première fois que j’entends ça...
Peux-tu donner un exemple STP.

Pour m'a part j'ai rencontré des normes de codage (MISRA en l’occurrence), dans laquel il est interdit d'utiliser un type primitif (int char double etc...) sans l'encapsuler dans un typedef.
J'ai du faire truc de genre typdef int int_t

[Bktero]

Du coup, je jette un oeil à la norme C99. Section 7.18.1: integer types. Je suis très étonné mais les "Exact-width integer types" ne sont pas obligatoires alors que les "Minimum-width integer types" et les "Fastest minimum-width integer types" le sont.

J'étais certain que c'était l'inverse.

J'ai du faire truc de genre typdef int int_t

C'est vilain de devoir en arriver là quand même ^^

[Neckara]

Première fois que j’entends ça...
Peux-tu donner un exemple STP.

Si les bytes sont codés sur 9 bits au lieu de 8 par exemple.
Mais c'est un cas qui est quand même assez rare et là on fera de l'embarqué donc il y a fort à parier que même si le code utilisait int au lieu de int32_t, cela poserait des problèmes.

Après on a int_least32_t si on veut vraiment gérer les cas "extravagant".

Personnellement, je ne pense pas qu'il y ai de raison, aujourd'hui, d'utiliser char, short, (long (long) ) int pour stocker des entiers.

[Médinoc]

En fait, je pense qu'on devrait plutôt utiliser les least ou fast par défaut, et ne se tourner vers les exacts que si on en a explicitement besoin.