Discussion :

[Invité]

Bonjour à tous

j'ai pas trés bien compris la difference entre une variable de type int et une variable de type short

merci

[grim7reaper]

Salut,

La différence c‘est qu‘un short peut être plus petit qu‘un int (en revanche, un short ne sera jamais plus grand qu‘un int).
Ils peuvent aussi avoir la même taille, ça dépends des architectures.

[Mipwiq]

La différence se passe au niveau de la mémoire.

En mémoire un int est codé sur 4 bytes, il peut prendre des valeurs entre -2147483648 et 2147483647.
Alors qu'un short est lui codé sur 2 bytes, il peut donc prendre des valeurs entre -32768 et 32767.

Cette différence de taille en mémoire est important lorsque tu travailles sur de petites mémoires, par soucis d'optimisation il vaut mieux parfois choisir un short plutôt qu'un int.

[grim7reaper]

En mémoire un int est codé sur 4 bytes, il peut prendre des valeurs entre -2147483648 et 2147483647.
Alors qu'un short est lui codé sur 2 bytes, il peut donc prendre des valeurs entre -32768 et 32767.

Ça n‘est absolument pas garanti.
Ça peut être le cas (et c‘est assez souvent le cas sur les ordinateurs 32-bit), mais il ne faut pas se baser sur cette hypothèse.
J‘ai déjà utilisé des systèmes où un int a exactement la même taille qu‘un short.

[Neckara]

Bonjour,

La FAQ C a la réponse à votre question

[sevyc64]

La réponse exacte est :

Un short est codé sur 2 octets, 16 bits. Quelque soit le système, c'est toujours vrai.

La taille du Int va dépendre, elle, de la plateforme ciblée. Elle peut être de 2, 4 ou 8 octet.
Bien souvent sur une plateforme 16 bits, le int sera de taille 2 octets soit 16 bits, sur une plateforme 32bits, le Int aura généralement une taille de 4 octets soit 32bits, sur une plateforme 64 bits le Int passera à 8 octets soit 64 bits.


Le Int est le pire type qui existe quelque soit le langage (et paradoxalement aussi le plus utilisé) car il n'a pas de taille précisément définie de manière absolu.

Pour finir, le Int représente généralement la taille minimum réelle (à cause de l'alignement mémoire) occupé par une variable en mémoire même d'un type ayant une taille inférieure.

[jabbounet]

La différence se passe au niveau de la mémoire.

En mémoire un int est codé sur 4 bytes, il peut prendre des valeurs entre -2147483648 et 2147483647.
Alors qu'un short est lui codé sur 2 bytes, il peut donc prendre des valeurs entre -32768 et 32767.

Cette différence de taille en mémoire est important lorsque tu travailles sur de petites mémoires, par soucis d'optimisation il vaut mieux parfois choisir un short plutôt qu'un int.

pour compléter, la norme C par exemple définit les taille minimum pour les différents types d'entiers mais pas de maximum.

pour connaitre la taille réel d'un type donné en c tu peux utiliser sizeof.

Si tu as besoin de contrôler précisément la taille mémoire de tes entier tu peut te tourner vers les types entier a taille fixe intN_t et uintN_t ou N prend la taille que tu souhaite (int8_t, int16_t, int32_t, ...)

[Bktero]

Les réponses de sevyc64 et Mipwiq ne sont pas (complètement) vraies; celles de Neckara et grim7reaper le sont. Les normes C ne définissent pas de tailles exactes pour chaque type mais une taille minimale. Les entiers de types int et short ont la même taille minimum requise par la norme : 2 octets. Mais rien ne garantit que la taille pour une implémentation donnée soit effectivement 2 octets ni que les deux tailles soient les mêmes. Tout ce qu'on sait, c'est que 2 <= sizeof short <= sizeof int.

En plus de la FAQ Developpez, on pourra lire http://c-faq.com/decl/inttypes.html ou la norme n1256 à la section 5.2.4.2.1 Sizes of integer types <limits.h>.

Note : dans une première version erronée de ce message, j'avais écris 4 octets et non 2, d'où les messages suivants.

[Neckara]

Les entiers de types int et short ont la même taille minimum requise par la norme : 4 octets.

4 octets ? N'est-ce pas plutôt 2 octets ?

[sevyc64]

Désolé de ne pas avoir fait attention que l'on était dans la rubrique C. Ma réponse se voulait généraliste tous langages confondus.

Par contre je surpris quand tu dis que le short comme le int a une taille de 4 octets. Dans ma mémoire, le short avait bien une taille de 2 octets quand au Int il avait une taille de 2 octets (à l'époque ou j'ai appris le C sur des processeurs 16bits) et 4 octets sur les plateformes 32bits.

Et je suis encore plus surpris quand tu dis que "Les normes C ne définissent pas de tailles exactes pour chaque type mais une taille minimale".
Certes je n'ai pas la connaissance absolue, et certainement des lacunes mais pour moi, les types Byte, Short, Long, DLong (long long), Float (single) et Double ont des tailles précisément définies et fixes indépendamment de tous langages. Que les normes C redéfinissent ces types en fixant pas de taille maxi (de taille fixe même) est, à mon avis, une grossière erreur.
Je n'avais pas souvenir d'une telle subtilité.

Concernant le type Int, oui, lui, n'est défini par aucune norme et peut correspondre à un Int16 (Short), Int32 (Long) ou un Int64 (Dlong), et probablement dans le futur à un Int128 qui n'existe pas encore.

[Invité]

Merci de vos réponse

si j'ai bien compris c'est uen question de mémoire .

[Médinoc]

Pour être précis, c'est une question de taille du nombre en mémoire et de valeurs minimale/maximale stockable dedans.

Si tu as un nombre allant de 0 à 99999, tu n'as aucune garantie de pouvoir faire marcher le programme sur n'importe quelle plate-forme si tu le stocke dans un short ou un int. Si tu le stockes dans un long, tu as cette garantie.

Ensuite, certaines plate-formes apportent des garanties en plus de la norme; ainsi, sous un Windows 32 bits et supérieur, tu as la garantie de pouvoir stocker ton nombre dans un int. Mais seulement tant que tu restes sur de telles plate-formes.

Tout ce qu'on sait, c'est que 2 <= sizeof short <= sizeof int

En fait, pour le 2 <=, je ne pense pas que ce soit garanti non plus. Tu peux avoir des plate-formes sur lesquelles CHAR_BIT >= 16, auquel cas sizeof short peut être 1.
La garantie, c'est que:

• SHRT_MIN <= -32767 et SHRT_MAX >= 32767
• LONG_MIN <= INT_MIN <= SHRT_MIN et LONG_MAX >= INT_MAX >= SHRT_MAX
• LONG_MIN <= -4294967295 et LONG_MAX >= 4294967295
• CHAR_BIT >= 8 et sizeof(char) == 1

Après, dans la pratique, sur une plate-forme Windows 32 bits (et la plupart des plate-formes 32 bits, en fait; mais pas toutes), on a les valeurs suivantes:

• SHRT_MIN == -32768 et SHRT_MAX == 32767
• INT_MIN == LONG_MIN == -4294967296 et INT_MAX == LONG_MAX == 4294967295
• CHAR_BIT == 8
• sizeof(short) == 2 et sizeof(int) == sizeof(long) == 4

[Bktero]

4 octets ? N'est-ce pas plutôt 2 octets ?

Grossière erreur d'inattention : c'est bien une taille minimale de 2 octets ! J'ai édité mon message précédent en conséquence.

Dans ma mémoire, le short avait bien une taille de 2 octets quand au Int il avait une taille de 2 octets (à l'époque ou j'ai appris le C sur des processeurs 16bits) et 4 octets sur les plateformes 32bits.

Sur PC 32 bits, c'est généralement le cas : short sur 16 bits et int sur 32 bits.

Et je suis encore plus surpris quand tu dis que "Les normes C ne définissent pas de tailles exactes pour chaque type mais une taille minimale".

http://en.wikipedia.org/wiki/C_data_types pour info

Que les normes C redéfinissent ces types en fixant pas de taille maxi (de taille fixe même) est, à mon avis, une grossière erreur.

Oui et non. Le C est un langage proche de la machine, les tailles des entiers s'adaptent au processeur. Il y a sûrement des raisons à cette "imprécision".

En fait, pour le 2 <=, je ne pense pas que ce soit garanti non plus. Tu peux avoir des plate-formes sur lesquelles CHAR_BIT >= 16, auquel cas sizeof short peut être 1.

J'avoue ne pas avoir pensé à ce cas "tordu"... En fouillant un peu, je lis dans la norme :

6.5.3.4 The sizeof operator
[...]
2 The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type.

Je présume donc que ça rendra 2 quand même (avec la petite approximation byte == octet).

La plage définie par la norme montre en tout cas une taille de 16 bits = 2 octets :

Code :

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

1
2
3
4
5.2.4.2.1 Sizes of integer types <limits.h>
[...]
maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 2^16 - 1

[souviron34]

Oui et non. Le C est un langage proche de la machine, les tailles des entiers s'adaptent au processeur. Il y a sûrement des raisons à cette "imprécision".

Il me semble, oui, puisque c'est justement ce qui permet de définir l'architecture

Une architecture est dite 32-bits SI un entier y est représenté avec 32 bits

Le nombre de bits associé à une architecture est - traditionellement - le nombre de bits nécessaire pour représenter un entier.. (et/ou un "float")

Ce qui fait ensuite la différence, ce sont les appellations des entiers..

Par usage - développement et expansion des diverses architectures - un "SHORT" est censé faire la moitié en nombre de bits ce ce que fait un entier normal... (16 bits sur un architcture 32 bit, mais sur une architecture 16 bits il en fera 8)

Le "INT" est censé être directement l'association de l'architecture :16 bits => int = 16 bits, 32 => int = 32 bits, 64 => int = 64 bits..

Le "long" est une appellation des entiers correspondant au "double précision" des floats..

[Bktero]

un "SHORT" est censé faire la moitié en nombre de bits ce ce que fait un entier normal... (16 bits sur un architcture 32 bit, mais sur une architecture 16 bits il en fera 8)

Non : il fera au moins 16 bits !

J'ai une fois aussi vu des shorts qui faisaient la même taille que les int qui faisaient 32 bits (c'était un microcontrôleur 32 bits).

[souviron34]

Non : il fera au moins 16 bits !

J'ai une fois aussi vu des shorts qui faisaient la même taille que les int qui faisaient 32 bits (c'était un microcontrôleur 32 bits).

peut-être, je n'ai jamais été très fort sur les shorts..

Ce que je sais par contre, c'est ce que j'ai dit juste au-dessus : et c'est dû à l'histoire du développement des micro-processeurs..

taille de l'architecture = taille d'un entier "par défaut" = int



En Fortran tu avais INTEGER, et tu précisais *2, *4, *8.. (le défaut, si on ne précisait pas, étant 2 sur 16 bits, 4 sur 32)

En fait, c'est qu'en sciences par exemple on ne s'est jamais vraiment posé la question : on était sur telle architecture, alors on avait droit à XX en entier et XXX en flottant, et ZZZ en flottant double-précision.. C'est - comme pression "utlisateur" - ce qui a poussé à la course au nombre de bits des processeurs (en dehors de la recherche technique)... La limite sur les entiers était le principal "obstacle" à circonvenir - les flottants pouvant souvent se réduire par facteur d'échelle .

Là où on se posait la question était juste pour "compresser" les résultats - par exemple les formats semi-binaires..

Je n'ai commencé à rencontrer des "SHORT" ou "u_16" que quand j'ai récupéré du code d'informaticiens.. Et mes codes ne font jamais appel à autre chose qu'à des int...


M$ a toujours eu un cas "à part" pour les floats, avec ce qu'ils appellaient "les far".. Mais ça a été - à ma connaissance - les seuls..

[Médinoc]

Au moins un de mes profs (de Système ou d'Architecture) m'a parlé d'une architecture dont les utilisateurs avaient tout mis sur 64 bits, car c'était la largeur native du processeur et ils avaient plus besoin de vitesse que d'économie de mémoire.
Ça veut dire sizeof(char) == sizeof(short) == sizeof(long long) == 1 et CHAR_BIT == 64.

Plus concret, je sais que le SDK pour TI-89 (processeur 16/32 Motorola 68000 possédant une taille de registre de 32 bits mais un bus de données de 16) comptait comme architecture 32 bits mais int y désignait des entiers courts (16 bits).

M$ a toujours eu un cas "à part" pour les floats, avec ce qu'ils appellaient "les far".. Mais ça a été - à ma connaissance - les seuls..

J'ai du mal à voir le rapport entre nombres à virgule flottante et far, qui pour moi se rapporte à la taille de pointeur, et est plus lié au matériel (intel 8086) qu'à l'éditeur de logiciels...

J'avoue ne pas avoir pensé à ce cas "tordu"... En fouillant un peu, je lis dans la norme :
<snip>
Je présume donc que ça rendra 2 quand même (avec la petite approximation byte == octet).

"byte" est, me semble-t-il, la plus petite unité adressable. En C, la plus petite unité adressable, c'est également le char, dont la taille (en bytes) vaut toujours 1.
Donc sur une architecture où CHAR_BIT == 16, considérer que byte == octet sort du domaine de l'approximation et entre dans celui de l'erreur. Et la taille d'un short 16 bits ici sera bel et bien 1 (vu que ce sera la même taille qu'un char)

[Metalman]

En fait, le 68000 est un 16bits... avec quelques exceptions sur 32bits (possibilité d'utiliser 2 cycles pour lire un mot de 32bits).
C'est le 68030 qui est 100% 32bits nativement.

Le CPU 64bits dont tu parles... ça ne serait pas les Alpha de DEC ?
J'ai de la doc @home sur tous ces CPU (et même quelques autres), j'irai rechercher ce soir si ça t'intéresse ! (toi ou quelqu'un d'autres).

EDIT : la plus petite unité adressable dépend "aussi" du CPU utilisé.
Sur 68000 par exemple, on ne peut pas accéder aux adresses impaires si je me souviens bien...
Du coup tu ne lis QUE des blocs de 16 bits, et pour accéder à 1 octet, tu dois utiliser le MOV de 8bits/1 octet poids fort ou poids faible.
J'irai vérifier tout ça !

[Médinoc]

Le CPU 64bits dont tu parles... ça ne serait pas les Alpha de DEC ?

Aucune idée, c'était il y a 8 à 10 ans et je ne sais même pas s'il nous avait donné le nom de l'archi.

[Bktero]

"byte" est, me semble-t-il, la plus petite unité adressable. En C, la plus petite unité adressable, c'est également le char, dont la taille (en bytes) vaut toujours 1.
Donc sur une architecture où CHAR_BIT == 16, considérer que byte == octet sort du domaine de l'approximation et entre dans celui de l'erreur. Et la taille d'un short 16 bits ici sera bel et bien 1 (vu que ce sera la même taille qu'un char)

Il y avait en effet des lacunes de ma part sur le sujet. Wikipédia encore une fois été mon ami : http://en.wikipedia.org/wiki/Byte#Common_uses