Bonjour à tous
j'ai pas trés bien compris la difference entre une variable de type int et une variable de type short
merci
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Quelle est la difference entre les variables de type INT et SHORT ?
Bonjour à tous
j'ai pas trés bien compris la difference entre une variable de type int et une variable de type short
merci
Dernière modification par Bktero ; 19/08/2013 à 12h31. Motif: Orthographe du titre
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.
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.
Ça n‘est absolument pas garanti.Envoyé par Mipwiq
Ç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.
Bonjour,
La FAQ C a la réponse à votre question
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.
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, ...)
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.
4 octets ? N'est-ce pas plutôt 2 octets ?
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.
Merci de vos réponse
si j'ai bien compris c'est uen question de mémoire .
Hello,
Il s'agit en fait de tailles minimum garanties : Le C t'assure que tu pourras représenter de manière sûre, avec chaque type, une plage de nombres définies. Le C est un langage conçu pour s'adapter à tous les types de plateforme possibles, en tout cas la plupart et certaines sont très exotiques.
Il se trouve que les tailles spécifiées par la norme dans limits.h (voir C99 §5.2.4.2) correspondent correspondent effectivement aux formats les plus courants et qu'on retrouve également dans les autres langages, mêmes anciens, ce qui est preuve de bon sens. Mais il est tout-à-fait possible que les types exacts ne soient pas disponibles sur la plateforme pour laquelle tu compiles. C'est vrai pour la largeur des nombres mais aussi pour certaines subtilités arithmétiques comme la représentation en complément à 1 (qui nous avait occupés ici). Et dans ce cas, le programme compilé est bien obligé de travailler sur le plus proche format par excès.
Si tu fixes la taille des nombres et donc, en particulier, leur comportement lors des débordements, il est possible que le C ne puisse absolument pas compiler sur certains produits. C'est pourquoi la norme définit en parallèle stdint.h qui, lui, établit la correspondance entre les types natifs et les formats d'entiers à nombre de bits fixe.
Dans le premier cas, tu es assuré de pouvoir utiliser les types natifs dans tous tes programmes et qu'ils seront valides sur les plages considérées. Dans le second, tu es sûr que les entiers auront le format souhaité s'ils sont disponibles, mais rien ne te garantit qu'il le soient.
C'est aussi pour cela que la norme définit un grand nombre de cas « indéfinis » ou « spécifiques à l'implémentation ». Ce n'est pas le signe d'un document mal finalisé mais, au contraire, d'une notion importante qu'il faut savoir utiliser partout où c'est judicieux et surtout pas ailleurs. Imposer un comportement par défaut sans justification valable ferme de facto à toutes les classes d'architectures qui ne suivent pas le courant principal, ou leur impose des contraintes coûteuses et inutiles. C'est souvent le cas en électronique numérique, et spécialement en VHDL : si on a besoin d'un signal valide pour certaines conditions mais dont la valeur n'a pas de sens lorsqu'elles ne sont pas réunies, forcer ce signal à une valeur par défaut comme on initialiserait une variable en programmation séquentielle peut s'avérer extrêmement gourmand en logique combinatoire. Tous ceux qui ont eu un jour à programmer un FPGA se sont retrouvés confrontés à ce problème en dépassant sa capacité et ont dû faire des compromis pour faire tenir le tout dedans.
Les nombres à virgules flottantes, maintenant, sont un poil différents parce qu'ils sont « artificiels ». Il faut donc choisir un format et s'y tenir. La norme la plus répandue à ce sujet est IEEE 754 et c'est celle qui est utilisée par la norme C. Outre le fait que ces nombres soient définis « en dehors » de C89/C99, il est nécessaire de fixer leur largeur à cause de l'aspect « composite » de leur format et parce que la largeur de l'exposant dépend aussi de celle de la mantisse.
C'est une erreur.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. …
Déjà, en soi, « byte » ne signifie pas « octet », contrairement à une idée répandue, mais plutôt quelque chose comme « boîte à bits ». Ensuite « short », « long » « dlong », etc. ne sont justement pas définis au niveau global, mais uniquement par les normes respectives des différents langages à leur propre niveau, et sont nés à la fois de l'état de l'art à l'époque de leur apparition et de l'historique qui menait jusqu'à cette époque.
Par exemple, « word » signifie « mot ». On parle de « mot » à partir du moment où on fait une composition lexicale insécable en elle-même mais formée de plusieurs atomes, qui correspondent aux caractères en théorie des langages. On a utilisé le terme « mot » dans des contextes assez différents notamment quand on travaillait au niveau du bit.
Et en particulier, on a longtemps travaillé sur huit bits, au point qu'encore aujourd'hui, c'est l'unité d'adressage native des x86 qui travaillent pourtant directement sur 32, voire 64 bits aujourd'hui. Quand on programmait en assembleur sur ce genre de machine, on travaillait donc au niveau de l'octet sur toutes les opérations arithmétiques, donc le résultat avait le même format que les opérandes SAUF pour la multiplication dont la largeur du résultat est par nature le double de celui des opérandes (au maximum). Si on considère qu'à partir du moment où on travaillait sur un format composé de plus d'un octet, on avait forcément un mot et qu'avec ça, le bus de ces micro-processeur mesurait généralement 16 bits de large (parce qu'il est inconcevable d'éditer un micro-processeur généraliste avec un plan de mémoire de seulement 256 octets), alors la plupart des micro-processeurs des années 1980, comme le 6809 ou le Z80, étaient conçus autour d'une architecture 8 bits mais étaient en pratique des 8/16 bits puisqu'ils étaient faits pour pouvoir agréger deux accumulateurs 8 bits en un registre de 16 (A et B vers D sur 6809 et B-C, D-E, H-L… sur Z80) en plus d'être dotés de registres d'index nativement 16 bits (à commencer par le pointeur de programme), mais sur lesquels on ne pouvait souvent faire que des translations d'adresse, soit des additions ou soustractions.
Tout ceci a ancré l'association « mot = 16 bits » dans l'esprit collectif par opposition à l'octet puis, lorsque les architectures plus étendues ont commencé à se développer, on a inventé les « double mots », etc. toujours par comparaison avec les formats les précédant immédiatement.
Répondre avec citation
Partager