Pourquoi le sizeof(int) == sizeof(long)?

Dans le programme énumérés ci-dessous, la sizeof(int) et sizeof(long) sont égaux sur ma machine (à la fois l'égalité de 4 octets (32 bits)). Une longue, autant que je sache, est de 8 octets. Est-ce correct? J'ai une machine 64 bits

#include <stdio.h>
#include <limits.h>

int main(void){
    printf("sizeof(short) = %d\n", (int)sizeof(short));
    printf("sizeof(int) = %d\n", (int)sizeof(int));
    printf("sizeof(long) = %d\n", (int)sizeof(long));
    printf("sizeof(float) = %d\n", (int)sizeof(float));
    printf("sizeof(double) = %d\n", (int)sizeof(double));
    printf("sizeof(long double) = %d\n", (int)sizeof(long double));
    return 0;
}
Voir this
Je pense que la sortie de votre code répond à votre question.
Eh bien, un exemple de code ne parle pas vers la norme depuis les compilateurs peuvent ne pas être conformes, peut avoir la mise en œuvre des comportements spécifiques ou peuvent avoir des extensions. Donc un exemple de code ne prouve pas ce qu'elle devrait être.
sa question ne mentionne rien à propos de la norme. Sa question était " Une longue, autant que je sache, est de 8 octets. Est-ce correct?' La réponse, évidente, à partir de son code, est "Non, un long sur votre ordinateur, avec votre compilateur, est de 4 octets".

OriginalL'auteur ChrisMcJava | 2013-09-19

  1. 23

    Une longue, autant que je sache, est de 8 octets. Est-ce correct?

    Non, ce n'est pas correct. Le C et le C++ spécifications seul état qui doit être supérieur ou égal à 32 bits. int peut être plus petit, mais sur de nombreuses plates-formes, en C et C++, long et int sont à la fois 32 bits.

    C'est une très bonne raison pour préférez une largeur fixe les types d'entiers comme int64_t s'ils sont disponibles et que vous êtes à l'aide de C99 ou un cadre qui vous offre un type équivalent.

    Et sizeof(long) est de 8 octets sur mon très typique 64b de la machine, donc je trouve "sur la plupart des machines" est difficile à accepter.
    Une machine n'est ni une œuvre, ni détermine quelle est la taille long est dans la mise en œuvre de ciblage de la machine. Voulez-vous dire sizeof(long) est de 8 octets dans votre très typique C mise en œuvre?
    Qui a dit "sur la plupart des machines"? Le sizeof long même sur les ordinateurs 64 bits est également dépend du compilateur et de ses options. Sur ma machine 64 bits, 4 de 4 compilateurs défaut sizeof(long) 4. Un compilateur permet taille 8.
    C'est pourquoi j'ai utilisé de la "plate-forme", pas à la machine par la plate-forme, je suis à la spécification de la machine + c'est l'exécution.
    L'original de la réponse contenue quelque chose comme "typique <texte>" c'est pourquoi mon commentaire a obtenu le plus de voix. Et la réponse originale à cette question n'est mentionné qu'en C++, sans C. Content de voir que l'amélioration dans le temps 🙂

    OriginalL'auteur Reed Copsey

  2. 4

    Cela dépend de votre ABI. Si vous utilisez Windows, Microsoft a choisi une LLP64 modèle, long et int sont à la fois 32 bits, alors que long long et les pointeurs sont des 64 bits dans les versions 64 bits, pour des raisons d'héritage.

    La plupart des plates-formes UNIX choisi un LP64 modèle, ce qui rend int 32-bits, long, long long, et des pointeurs 64-bits, pour les versions 64 bits.

    Mais, comme Reed Copsey notes, de la norme, seuls les états longueurs minimales, et les longueurs relatives. Et long doit être supérieure ou égale à la longueur de int.

    OriginalL'auteur chmeee

  3. 4

    C est pas Java et C#. Comme d'autres ont écrit, C spec etats minimum des longueurs et des longueurs relatives. Pourquoi? C a été conçu pour être de bas niveau et de le compiler et de l'exécuter sur pratiquement n'importe quel matériel jamais fait.

    Si un spec promet le programmeur trop, sa mise en œuvre peut être délicat (et lent) lorsque le matériel ne prend pas en charge une telle chose. Java et C# les développeurs ne se soucient pas trop, ils aiment la commodité de leurs langues de niveau plus élevé d'emplois et n'hésitez pas à installer de grandes machines virtuelles qui prennent soin de l'accomplissement de toutes les promesses (ou au moins la plupart d'entre eux).

    C programmeurs veulent avoir le contrôle sur le code même de la machine niveau de l'instruction. Le contrôle complet sur le matériel. Seulement de cette manière peut toutes les fonctionnalités matérielles être utilisé, et le maximum de performance atteint. Mais vous devez être prudent avec vos hypothèses sur le matériel que vous utilisez. Comme toujours, avec un grand pouvoir vient une grande responsabilité.

    Juste pour illustrer le fait que: C n'assume pas les octets de 8 bits. Voir CHAR_BIT dans <limits.h>.

    Une question connexe est celle de Taille d'un entier en C.

    Certains aspects de la norme C ont vraiment mal vieilli. Le standard des types d'en-têtes d'améliorer un peu les choses, mais pour autant que je sache il n'y a rien qui n'est pas vraiment clair si par exemple, une comparaison entre un unsigned "au-moins-8 bits type" et signé "exactement-de 16 bits de type" sera signé ou non signé. Une mise en oeuvre des opérations sur des choses plus courtes que les 32 bits sont possibles mais plus lents que ceux sur les grands types peuvent utiliser une variable de 32 bits pour le premier type et un 16-bit pour le second. Je ne pense pas qu'il y a moyen de le physiquement plus grand type pourrait avoir un petit rang, et donc...
    ...Je pense que sur les plates-formes où le "au moins 8 bits type" était supérieure à celle d'un "exactement 16 bits de type", son rang devrait être plus élevé, ce qui implique que la comparaison devrait être faite non signés. Ayant typedefs pour certaines tailles de types, sans préciser de quelle signés et non signés, les valeurs vont interagir semble être une recette pour le désastre. Si l'on a été la conception d'une nouvelle langue, on pourrait distinguer entre les valeurs non signées qui sont utilisés pour maintenir les choses qui doivent envelopper, et ceux qui sont utilisés pour contenir des nombre. On pourrait alors préciser que la somme de...
    ...un emballage chose et un nombre serait un emballage chose de la même taille que l'original (peut-être d'avertissement si le nombre est plus grand), tandis que la somme de deux nombres serait un type assez grand pour contenir le résultat, si une telle chose existe. Une comparaison entre les enveloppant les choses et les numéros de nécessiterait d'être jeté à l'autre, et les comparaisons entre signés et non signés, les valeurs devraient être spécifiés pour être arithmétiquement correcte. De telles règles pourraient éliminer en grande partie le cas où le type de classement de la matière. Malheureusement, ils seraient incompatibles avec C tel qu'il existe.

    OriginalL'auteur Palec

  4. 3

    Non, la norme définit les minimums qui pour long est 4 bytes et int est 2 bytes. Comme par le Projet de norme C99 section 5.2.4.2.1 Tailles des types d'entiers paragraphe 1 dit:

    [...]Leur mise en œuvre-la définition des valeurs doit être égale ou de plus grande ampleur[...]

    et pour long nous avons:

     LONG_MIN -2147483647 //-(2^31 - 1)
 LONG_MAX +2147483647 //2^31 - 1

    qui est 4 bytes. Par souci d'exhaustivité, nous avons les éléments suivants pour int:

     INT_MIN -32767 //-(2^15 - 1)
 INT_MAX +32767 //2^15 - 1

    qui est 2 bytes.

    Non, les types sont spécifiés dans le nombre de bits. C ne dit rien à propos de octets, seulement sur le nombre minimum de bits qui composent chaque type. Ce n'est pas seulement pédantisme, parce que vous ne savez pas à l'avance ce que CHAR_BIT sera jusqu'à ce que vous l'examiner.
    C dit un beaucoup à propos des octets. Mais le minimum requis tailles des types d'entiers ne sont pas définies, soit sous forme de bits ou d'octets; ils sont définis comme des plages de valeurs. int a une portée d'au moins -32767 à +32767. Nous pouvons déduire de la plage que sa taille est d'au moins 16 bits, et on peut en déduire à partir de la plage et de la valeur de CHAR_BIT combien d'octets (annotation plus de rembourrage bits), mais aucun n'est spécifié directement.
    Il est tout à fait possible pour long et int à la fois à 1 octet de la taille (mais seulement si CHAR_BIT >= 32).
    votre dernier commentaire exprime beaucoup plus succinctement que le mien quel est le problème avec cette réponse - tout type peuvent avoir une taille de 1, si CHAR_BIT est suffisamment important (et qui n'est pas inconnue; les Dsp n'ont pas l'aborder de petits types).

    OriginalL'auteur Shafik Yaghmour