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.