Bonjour,
 
donc sous architecture Unix, quelle est la réelle différence entre short int, int, et long int.
Je sais que short int c'est du 16 bits et long int du 32 bits, mais dans ce cas int ???
 
De plus beaucoup de fonctions du C attendent en paramètre un int.
Puis-je leur fournir du short int ou du long int ???
 
Merci

int c 8 bit sur une arch 8bits, 16bits sur une arch 16bits, 32 sur une arch 32bits, ...

 
bah ça n'au aucun intérêt alors ???
Pourquoi ne pas utiliser des types fixes ???
 
Bizarres, faudrait m'éclairer d'avantage !
 
Merci en tk !

short <= int <= long
c'est la seule chose qui est sûre

char : 1 octet
short : 2 octets
long : 4 octets
 
int et double : dépends de la machine
 
Le type int est facile à adresser directement par le pc car il est directement adressable, pour les types plus petit, je pense qu'il y a des manips à faire en plus (décalage et masquage) par le pc.
 
Donc pour les développements de brutes le int est pratique.
 
Arrêtez moi si je dis des conneries
 
vw

antp a écrit a écrit : short <= int <= long c'est la seule chose qui est sûre

 
même pas, car le long c'est 4 octets, donc sur une machine 16 bits, un int est plus petit qu'un long.

antp a écrit a écrit : short <= int <= long c'est la seule chose qui est sûre

 
Bah nan !
 
sur une architecture 16 bits, (short = int) < long
et sur une 32 bits : short < (int = long)
 
Mais je vois pas l'intérêt de ce type de variable ...
 
 

Bah si !
 
<= : inférieur ou égal ...

 
Et sur une machine 64 bits ?

sizeof()  

Combi_A_Vendre a écrit a écrit : Et sur une machine 64 bits ?

<= a le même comportement sur une machine 8, 16, 32 ou 64 bits

Combi_A_Vendre a écrit a écrit :     Et sur une machine 64 bits ?

 
ben le int est entre 16 et 32 bits quand même.
 
Il me semble que des entier sur 64 bits existent maintenent mais je sais pas si c standard.

http://ccrma-www.stanford.edu/~jos [...] mbers.html
 
Byte sizes of GNU C/C++ data types for 64-bit architectures
Type Bytes  
short  2  
int  4  
long  8 (4 bytes on 32-bit machines)  
long long  8 (may become 16 bytes)  

 
Bon ok, mes infos retardaient un peu  

 
ouais on va devoir les renvoyer à l'école primaire

 
bah oui ça confirme ce que j'ai dit

De toute manière si tu veux un truc précis d'un point de vue taille fait un champ de bit, là au moin...

encore que, tu n'es pas sûr de l'espace mémoire qu'il occupera, vu que c'est arrondi à la taille supérieur qui plaît le plus au compilo

antp a écrit a écrit : encore que, tu n'es pas sûr de l'espace mémoire qu'il occupera, vu que c'est arrondi à la taille supérieur qui plaît le plus au compilo

 
Ouai, mais t sûr d'avoir au minimum la taille que tu veux.

Et puis ça se désactive l'alignement des données.

letoII a écrit a écrit : De toute manière si tu veux un truc précis d'un point de vue taille fait un champ de bit, là au moin...

 
Les champs de bits peuvent etre interprétés différement selon le compilo, c'est donc à déconseillé pour le multiplateforme, multi os ou multo compilo.
 
vw

 
Pour l'alignement des données, vous pouvez utiliser la directive pragma packed pour choisir l'alignement au bit prés dans une structure.
 
vw

 
Qu'est ce que tu entend par interprété différament?

 
J'ai eu le problème sous Unix avec GCC et un compilateur Unix dont je ne souviens plus le nom.
Le but était de faire passer un buffer par une liaison série SPI entre processeurs motorola.
Pour un processeur j'utilisais GCC et pour l'autre processeur un autre personne utilisait un autre compilo.
 
La même définition du suivant donnait des mappings mémoires différents selon le compilateur.  
typedef struct
{
    ulong toto1:2;
    ulong toto2:5;
    ...
}
 
En informatique industrielle beaucoup de personnes évitent les champs de bits pour cette raison.
 
vw