Taille des types C

AliGatorAliGator Membre, Modérateur
janvier 2006 modifié dans API AppKit #1
Etant donné que la doc Cocoa dit que count renvoie un "unsigned", et que objectAtIndex: prend un "unsigned", etc, enfin que le type des index est toujours "unsigned"...
L'index est donc forcément un "unsigned", sous-entendu "unsigned int". Il me semble que sur nos processeurs, cela sous entend "short" par défaut pour les int, si je ne me trompe... (un bête [tt]NSLog(%"taille : %d",sizeof(unsigned));[/tt] permettra de vérifier si c'est un short (2) ou un long (4)).

Tiens, remarque, c'est pas bête comme question : est-ce qu'un processeur 64 bits ne prendrait pas par défaut int = long ?

Pour rappel :
- char = 1 octet = 8 bits
- short = 2 octets = 16 bits
- long = 4 octets = 32 bits
- long long = 8 octets = 64 bits

Réponses

  • BruBru Membre
    07:33 modifié #2
    dans 1137766009:

    Il me semble que sur nos processeurs, cela sous entend "short" par défaut pour les int, si je ne me trompe... (un bête [tt]NSLog(%"taille : %d",sizeof(unsigned));[/tt] permettra de vérifier si c'est un short (2) ou un long (4)).

    Tiens, remarque, c'est pas bête comme question : est-ce qu'un processeur 64 bits ne prendrait pas par défaut int = long ?

    Pour rappel :
    - char = 1 octet = 8 bits
    - short = 2 octets = 16 bits
    - long = 4 octets = 32 bits
    - long long = 8 octets = 64 bits


    Sur architecture PPC, un int fait 4 octets : donc sizeof(int)=sizeof(long).

    Sur un proc 64 bits, on peut donc supposer que le int fera 8 octets (comme le long long)...

    .
  • AliGatorAliGator Membre, Modérateur
    07:33 modifié #3
    Oui j'ai voulu donner des compléments d'infos après quelques recherches mais OC était down.

    Déjà  ce qu'on peut dire :
    - le type "unsigned" tout court suppose "unsigned int"
    - le type "signed" tout court suppose "signed int"
    - le type "int" : je ne sais pas si par défaut c'est signed ou unsigned si on précise pas (pour tous les types C d'ailleurs genre long, short, char, etc) ?
    Et concernant la taille des différents types, en tout cas de ce que j'ai pu lire mais ce n'est pas de source sûre :
    - un "int" fait la taille des entiers manipulés par le processeur. Donc 4 octets (long) sur les architectures 32 bits, 2 octets (short) sur les archi 16 bits, et 8 octets (long long) sur les archis 64 bits.
    - Pour le reste, char = 8 bits, short = 16 bits, long = 32 bits, long long = 64 bits, ça reste immuable.
    - Et pour les float, jusqu'à  présent les processeurs de nos ordis utilisent la virgule flottante, donc IEEE 754. Alors que dans les microcontrôlleurs et FPGA & co, on tend de plus en plus à  revenir à  la virgule fixe... Mais pour l'instant ça n'a pas déteint sur nos processeurs d'ordis
    - Après, un float est-il par défaut un single ou un double ? single étant des float sur 32 bits (1 bit de signe, 8 pour l'exposant, 23 pour la mantisse) et double des float sur 64 bits (1+11+52, de tête)

    Ca serait intéressant de s'assurer de tout ça... en particulier pour les cas où on ne précise pas la taille de stockage explicitement ;)
  • BruBru Membre
    07:33 modifié #4
    dans 1137940369:

    Et concernant la taille des différents types, en tout cas de ce que j'ai pu lire mais ce n'est pas de source sûre :
    - un "int" fait la taille des entiers manipulés par le processeur. Donc 4 octets (long) sur les architectures 32 bits, 2 octets (short) sur les archi 16 bits, et 8 octets (long long) sur les archis 64 bits.
    - Pour le reste, char = 8 bits, short = 16 bits, long = 32 bits, long long = 64 bits, ça reste immuable.


    Les options -m32 et -m64 de GCC semblent te contredire (options spécifiques à  l'architecture powerpc)...

    En mode 64 bits (option -m64), il apparaitrait que le type long soit de 64 bits, et donc par conséquence, le long long 128 bits. Par contre, le int resterait à  32 bits !

    Mais tout cela reste confus.

    .
  • AliGatorAliGator Membre, Modérateur
    07:33 modifié #5
    En continuant mes recherches j'ai trouvé (c'est con j'ai pas gardé le lien) de messages de mailing lists qui disait en gros ceci :
    - un int = taille de l'entier "de base" géré par le processeur (32 bits sur les archis 32 bits... ou donc j'imagine avec l'option -m32, 64 bits sur les archis 64 bits, ou -m64...)
    - un short = taille inférieure ou égale à  un int (donc pas forcément que 16 bits !)
    - un long = taille supérieure ou égale à  un int (donc pas forcément 32 bits)
    - un long long = taille supérieure à  un "long"
    - char = la plus petite unité manipulable par les variables (autrement dit un octet unique)

    Mais bon ces définitions me laissent sceptique...

    PS pour les modos : on ne splitterait pas le post en 2 ("NSArray" / "taille des types de données C") ?
  • tabliertablier Membre
    07:33 modifié #6
    Je suis assez d'accord avec la dernière explication.
    Les processeurs sont capables de travailler sur des largeurs de bits multiples de 8 (ne parlons pas des "slices").
    La dénomination de ces quantités est affaire de définitions Informatiques liées à  des bibliothèques et des compilateurs.
    Il me semble que Byte est toujours un 8 bits, Integer est en général taillé sur la largeur standard de mémoire utilisé par le processeur.
    Long est souvent le double de l'int. et 'long long'? eh bien cela dépend en pascal j'ai utilisé des "long long" de 80 bits! mais en C c'est en général le double du long.
    Pour le short, c'est souvent une valeur non signée de longueur "Integer" (suivant les compilateurs).
    Et le "Char" est bien souvent défini comme "unsigned BYTE".


  • maconnectmaconnect Membre
    07:33 modifié #7
    c'est peut-être un peu tard, mais pas besoin de se casser la tête avec ça. Il suffit d'utiliser:

    UInt32, UInt64,.. et compagnie, et on est toujours sûr d'avoir ce qu'on veut
Connectez-vous ou Inscrivez-vous pour répondre.