Pourquoi C de caractères littéraux entiers au lieu de caractères?

En C++, sizeof('a') == sizeof(char) == 1. Cela semble logique, puisque 'a' est un caractère littéral, et sizeof(char) == 1 tel que défini par la norme.

En C cependant, sizeof('a') == sizeof(int). C'est, il semble que C les chaînes de caractères sont en fait des entiers. Quelqu'un sait-il pourquoi? Je peux trouver beaucoup de mentions de ce C caprice mais pas d'explication pour pourquoi il existe.

  • sizeof serait juste de retour de la taille d'un byte ne serait-il pas? Ne sont pas un char et int de la même taille?
  • C'est probablement le compilateur (et de l'architecture) à charge. Soin de dire ce que vous utilisez? La norme (au moins jusqu'à '89) a été très lâche.
  • pas de. un char est toujours de 1 octet grand, donc sizeof('a') == 1 toujours (en c++), tandis qu'un int peut théoriquement être sizeof de 1, mais cela nécessiterait un octet ayant au moins 16 bits, ce qui est très rare 🙂 donc sizeof('a') != sizeof(int) est très probablement en C++ dans la plupart des implémentations
  • ... alors qu'il est toujours mal en C.
  • 'a' est un int en C - période. C y suis arrivé du premier C fait les règles. C++ a changé les règles. Vous pouvez argumenter que le C++ règles plus de sens, mais le changement de la C règles permettrait de faire plus de dégâts que de bien, de sorte que le C standard comité judicieusement n'a pas touché cette.
  • Jonathan, juste pour être clair, mon "c'est toujours mal au C" n'est pas à dire que C est toujours mal:), cela signifie que sizeof('a') == sizeof(int) est toujours vrai dans C . votre commentaire ressemble vous un commentaire sur quelque chose je l'ai dit dans mon commentaire 🙂

InformationsquelleAutor Joseph Garvin | 2009-01-11
  1. 36

    discussion sur même sujet

    "Plus spécifiquement l'intégrale des promotions. Dans le K&R C était pratiquement (?)
    impossible d'utiliser une valeur de caractère, sans qu'il soit promu en int premier,
    afin de faire la constante de caractère int en premier lieu, éliminé cette étape.
    Y étaient et sont toujours des multiples de constantes de caractères tels que "abcd" ou cependant
    ils seront nombreux à s'insérer dans un int."

    • Multi-caractères constantes ne sont pas portables, même entre les compilateurs sur une seule machine (bien que GCC semble être auto-cohérente à travers les plates-formes). Voir: stackoverflow.com/questions/328215
    • Je tiens à souligner que: a) Cette citation est non; la citation simplement dit: "seriez-vous en désaccord avec cette opinion, qui a été posté dans un fil de discuter de la question en cause?" ... et b) Il est ridicule, car un char variable n'est pas un int, donc de la rendre un caractère constant de être un est un cas spécial. Et il est facile d'utiliser une valeur de caractère sans promotion: c1 = c2;. Otoh, que, c1 = 'x' est une baisse de la conversion. Plus important encore, sizeof(char) != sizeof('x'), ce qui est grave, la langue de botch. Comme pour les jeux de caractères multioctets constantes: ils sont la raison, mais ils sont obsolètes.
    InformationsquelleAutor Malx
  2. 27

    La question de départ est "pourquoi?"

    La raison en est que la définition d'un caractère littéral a évolué et changé, tout en essayant de rester compatible avec le code existant.

    Dans les jours sombres de début C il n'y avait pas des types à tous. Par moment j'ai d'abord appris à programmer en C, les types avaient été introduites, mais les fonctions n'ont pas de prototypes pour indiquer à l'appelant de ce que les types d'arguments ont été. Au lieu de cela il a été standardisé que tout ce passé comme un paramètre devrait être la taille d'un int (ce qui inclus tous les pointeurs) ou qu'il serait un double.

    Cela signifie que lorsque vous écrivez la fonction, tous les paramètres qui n'étaient pas en double ont été stockées sur la pile comme ints, peu importe comment vous avez déclaré, et le compilateur de mettre le code dans la fonction pour gérer cela pour vous.

    Cela a rendu les choses un peu incohérente, de sorte que lorsque K&R écrivit son célèbre livre, dans la règle qu'un caractère littéral serait toujours promu un int dans une expression, pas seulement un paramètre de la fonction.

    Lorsque le comité ANSI première standardisé C, ils ont changé cette règle de manière un caractère littéral serait simplement un int, étant donné que cela semble un moyen plus simple de réaliser la même chose.

    Quand le C++ a été conçu, toutes les fonctions ont été tenus d'avoir plein de prototypes (ce n'est pas encore obligatoire en C, bien qu'il est universellement accepté comme une bonne pratique). De ce fait, il a été décidé qu'un caractère littéral peut être stocké dans un char. L'avantage de cette en C++ est qu'une fonction avec un char paramètre et une fonction avec un paramètre de type int ont des signatures différentes. Cet avantage n'est pas le cas chez C.

    C'est pourquoi ils sont différents. L'évolution...

    • +1 pour moi en fait de répondre à " pourquoi?". Mais je suis en désaccord avec la dernière déclaration, "L'avantage de cette en C++ est qu'une fonction avec un char paramètre et une fonction avec un paramètre de type int ont des signatures différentes" -- en C++, il est encore possible pour les 2 fonctions à paramètres de la même taille et les différentes signatures, par exemple void f(unsigned char) Vs void f(signed char).
    • John pouvait mettre c'est mieux, mais ce qu'il dit est essentiellement précis. La motivation pour le changement en C++, si vous écrivez f('a'), vous voulez probablement résolution de surcharge de choisir f(char) pour cet appel, plutôt que de f(int). La taille relative de int et char ne sont pas pertinentes, comme vous le dites.
    InformationsquelleAutor John Vincent
  3. 21

    Je ne connais pas les raisons spécifiques pour lesquelles un littéral de caractère en C est de type int. Mais en C++, il y a une bonne raison de ne pas faire de cette façon. Considérez ceci:

    void print(int);
void print(char);

print('a');

    Que vous attendez que l'appel à imprimer sélectionne la deuxième version de prendre un char. Ayant un caractère littéral étant un int rendrait impossible. Notez qu'en C++, les littéraux d'avoir plus d'un caractère toujours être de type int, bien que leur valeur est définie par l'implémentation. Donc, 'ab' a type int, tandis que 'a' a type char.

    • Oui, "la Conception et l'Évolution de C++", dit surchargé routines d'entrée/sortie ont été la principale raison C++ changé les règles.
    • Max, oui j'ai triché. j'ai regardé dans le standard dans la section compatibilité 🙂
    InformationsquelleAutor Johannes Schaub - litb
  4. 18

    à l'aide de gcc sur mon MacBook, j'ai essayer:

    #include <stdio.h>
#define test(A) do{printf(#A":\t%i\n",sizeof(A));}while(0)
int main(void){
  test('a');
  test("a");
  test("");
  test(char);
  test(short);
  test(int);
  test(long);
  test((char)0x0);
  test((short)0x0);
  test((int)0x0);
  test((long)0x0);
  return 0;
};

    qui lors de l'exécution donne:

    'a':    4
"a":    2
"":     1
char:   1
short:  2
int:    4
long:   4
(char)0x0:      1
(short)0x0:     2
(int)0x0:       4
(long)0x0:      4

    qui suggère qu'un personnage est de 8 bits, comme vous pensez, mais un caractère littéral est un int.

    • +1 pour être intéressante. Les gens pensent souvent que sizeof("un") et sizeof("") sont des char*s et doit donner 4 (ou 8). Mais en fait, ils sont char[]'s à ce point (sizeof(char[11]) donne 11). Un piège pour les débutants.
    • Un caractère littéral n'est pas promu à un int, c'est déjà un int. Il n'y a pas de promotion en allant sur que ce soit si l'objet est un opérande de l'opérateur sizeof. S'il y avait, ce serait la défaite sizeof du but.
    • Jeunes: Ya. De vérifier. Merci.
    InformationsquelleAutor dmckee
  5. 7

    En arrière quand C était écrit, le PDP-11 de la MACRO-11 de l'assemblée de la langue a:

    MOV #'A, R0      //8-bit character encoding for 'A' into 16 bit register

    Ce genre de chose est assez commun dans le langage d'assemblage - le faible taux de 8 bits tiendra le code de caractère, les autres bits égaux à 0. PDP-11 avait même:

    MOV #"AB, R0     //16-bit character encoding for 'A' (low byte) and 'B'

    Cela a fourni un moyen pratique pour charger des deux personnages dans la basse et haute octets de la 16 bits de registre. Vous pouvez ensuite écrire ailleurs, la mise à jour des données textuelles ou de l'écran de la mémoire.

    Ainsi, l'idée de caractères d'être promu au registre de la taille est tout à fait normal et souhaitable. Mais, disons que vous avez besoin pour obtenir 'A' dans un registre pas dans le cadre de la codées en dur opcode, mais à partir de quelque part dans la mémoire principale contenant:

    address: value
20: 'X'
21: 'A'
22: 'A'
23: 'X'
24: 0
25: 'A'
26: 'A'
27: 0
28: 'A'

    Si vous voulez le lire juste un 'A' à partir de ce mémoire principale dans un registre, qui aimeriez-vous lire?

    • Certains Processeurs ne peuvent directement prendre en charge la lecture d'une valeur 16 bits en 16 bits registre, ce qui signifierait une lecture à 20 ou 22 exigerait alors les bits de 'X' être nettoyé, et selon le boutisme de la CPU l'un ou l'autre aurait besoin de déplacement dans l'octet de poids faible.

    • Certains Processeurs peuvent exiger une mémoire aligné à lire, ce qui signifie que l'adresse la plus basse concernés doit être un multiple de la taille des données: vous pourriez être en mesure de lire les adresses, les 24 et 25, mais pas 27 et 28.

    Donc, un compilateur de générer du code pour obtenir Un " a " dans le registre peut préférer à perdre un peu plus de mémoire et d'encoder la valeur 0 'A' ou 'A' 0 - en fonction de l'endianness, et aussi de s'assurer qu'il est correctement aligné (à savoir pas d'un drôle d'adresse de mémoire).

    Ma conjecture est que C est tout simplement porté ce niveau de CPU centrée sur le comportement, la pensée de constantes de caractère occupant registre des tailles de mémoire, portant la commune d'évaluation de C comme un "assembleur de haut niveau".

    (Voir 6.3.3 sur la page 6-25 de http://www.dmv.net/dec/pdf/macro.pdf)

    InformationsquelleAutor Tony Delroy
  6. 6

    Je me souviens de la lecture de K&R et voir un extrait de code qui permettrait de lire un caractère à la fois jusqu'à ce qu'il a frappé des expressions du FOLKLORE. Depuis, tous les caractères sont des caractères valides dans un fichier/flux d'entrée, cela signifie que les expressions du FOLKLORE ne peut pas être n'importe quelle valeur char. Ce que le code a été de mettre à la lecture de caractères en un entier (int), puis de tester pour les expressions du FOLKLORE, puis convertir un char si il n'était pas.

    Je me rends compte ce n'est pas exactement la réponse à votre question, mais il serait un certain sens, pour le reste des chaînes de caractères pour être sizeof(int) si les expressions du FOLKLORE littérale était.

    int r;
char buffer[1024], *p; //don't use in production - buffer overflow likely
p = buffer;

while ((r = getc(file)) != EOF)
{
  *(p++) = (char) r;
}
    • Je ne pense pas que 0 est un caractère valide si.
    • Assurez-vous qu'il est. C'est le caractère null. Pensez à ce sujet. Pensez-vous qu'un fichier ne devrait pas être autorisé à contenir de zéro octets?
    • Un nul pourrait faire sens pour les données textuelles, mais si c'est du binaire, je pense \0 doit être considérée comme une valeur valide.
    • Lire wikipédia - "La valeur réelle des expressions du FOLKLORE est un système dépendant d'un nombre négatif, communément -1, qui est garanti pour être inégale à tout caractère valide code."
    • Comme Malx, dit - EOF n'est pas un type char - c'est un type int. getchar() et ses amis retourner un int, qui peut contenir n'importe quelle char ainsi que les expressions du FOLKLORE, sans conflit. Ce ne serait vraiment pas besoin littéral de caractères de type int.
    • EOF == -1 est venu longtemps après C des constantes de caractère, donc ce n'est pas une réponse et pas pertinente.

    InformationsquelleAutor Kyle Cronin
  7. 5

    Je n'ai pas vu une justification (C char littéraux être int types), mais voici quelque chose de Stroustrup avait à dire à ce sujet (de la Conception et de l'Évolution 11.2.1 - Fine-Grain Résolution):

    En C, le type d'un caractère littéral comme 'a' est int.
    Étonnamment, donnant 'a' type char en C++ ne cause pas de problèmes de compatibilité.
    Sauf pour le pathologique exemple sizeof('a'), tous les de construire qui peut être exprimé
    en C et C++ donne le même résultat.

    Donc, pour la plupart, il ne devrait causer aucun problème.

    • Intéressant! Un peu contredit ce que les autres ont dit à propos de la façon dont le C comité de normalisation "à bon escient" a décidé de ne pas supprimer ce caprice de C.
    InformationsquelleAutor Michael Burr
  8. 1

    C'est le bon comportement, appelé "font partie intégrante de la promotion". Il peut arriver dans d'autres cas également (principalement des opérateurs binaires, si je me souviens bien).

    EDIT: Juste pour être sûr, j'ai vérifié ma copie de Expert de la Programmation en C: Secrets Profonds, et je confirme qu'un char littérale n'est pas commencer avec un type int. C'est d'abord de type char mais quand il est utilisé dans un expression, il est promu à un int. Ce qui suit est cité dans le livre:

    Les chaînes de caractères de type int et
    ils y arriver en suivant les règles
    pour une promotion de type char. C'est
    trop brièvement couverts dans le K&R 1, à la page
    39, où il est dit:

    Tous les caractères dans une expression est
    converti en un entier (int)....Notez que
    toutes flottent dans une expression sont
    converti en double....Depuis un
    argument de fonction est une expression,
    les conversions de type également lieu lors de la
    les arguments sont passés à des fonctions: dans
    en particulier, char et short devenir int,
    flotteur devient double.

    • Si les autres commentaires sont pour le croire, l'expression 'a' part avec le type int -- aucune type de promotion est effectuée à l'intérieur d'un sizeof(). Que 'a' a le type int est juste un caprice de C il me semble.
    • Un char littérale t sont de type int. La norme ANSI/ISO 99 standard qualifie de "nombre entier de caractères constantes (à différencier de "wide constantes de caractère", qui sont de type wchar_t) et, plus précisément dit, "Un nombre entier de caractères constante de type int."
    • Ce que je voulais dire, c'est qu'il n'est pas démarrer avec de type int, mais plutôt converti en int char (réponse de la modification). Bien sûr, ce n'est probablement pas une préoccupation personne, sauf les rédacteurs du compilateur puisque la conversion est toujours fait.
    • Non! Si vous lire la norme ANSI/ISO 99 C standard, vous trouverez dans C, l'expression 'a' commence par de type int. Si vous avez une fonction void f(int) et une variable char c, alors f(c) est exécuter la promotion intégrale, mais f('a') n'est pas que le type de 'a' est déjà int. Étrange, mais vrai.
    • Malheureusement je n'ai pas accès à la norme. De toute façon, C99 a après K&R 1, donc je ne peux que supposer que c'était l'un de silencieux changements. Il ne fait aucune différence pour les programmeurs (même les rédacteurs du compilateur) de toute façon.
    • Le K&R citation est d'être mal interprété. Le caractère littéral de " a " jamais eu de type char, il est toujours int, en fonction de chaque C standard.
    • "Juste pour être sûr" - Vous pourriez être plus sûr en fait par lecture de la déclaration: "les chaînes de Caractères de type int". "Je ne peux que supposer que c'était l'un de silencieux changements" -- vous supposer à tort. Les chaînes de caractères en C ont toujours été de type int.
    • -1 Cette réponse est encore incorrecte et doit être supprimé. Voir C11 6.4.4.4/10: "An integer character constant has type int". Soit "au plus Profond des Secrets" est incorrect ou vous avez simplement mal compris.

    InformationsquelleAutor PolyThinker
  9. 1

    La raison historique à cela est que C, et de son prédécesseur, B, ont été à l'origine développé sur différents modèles de DEC PDP mini-ordinateurs avec différentes longueurs de mot, qui a soutenu 8 bits ASCII, mais ne pouvait effectuer l'arithmétique sur les registres. (Pas le PDP-11, cependant; c'est venu plus tard.) Les premières versions de C définie int être le natif word taille de la machine, et de toute valeur inférieure à un int devait être élargie à int afin d'être transmis vers ou à partir d'une fonction, ou utilisé dans un bit à bit, logique ou une expression arithmétique, parce que c'était la façon dont le matériel sous-jacent travaillé.

    C'est aussi pourquoi le entier les règles de la promotion continue à dire que tout type de données plus petit qu'un int est promu int. C implémentations sont également autorisés à utiliser un complément de mathématiques au lieu de complément à deux, pour les mêmes raisons historiques. La raison que octal personnage s'échappe et les constantes octales sont des citoyens de première classe par rapport à l'hexagone de même que ceux au début de DÉCEMBRE les mini-ordinateurs de mot tailles divisible en trois octets morceaux mais pas de quatre octets des amuse-gueules.

    • ... et char était exactement 3 octale long
    InformationsquelleAutor Davislor
  10. 0

    Je ne sais pas, mais je suppose que c'était plus facile à mettre en œuvre et il n'a pas vraiment d'importance. Il n'était pas jusqu'à ce que le C++ quand le type peut déterminer la fonction est appelée qu'il est nécessaire pour être fixé.

    InformationsquelleAutor Roland Rabien
  11. 0

    Je ne connaissais pas cet effet.
    Avant de prototypes existé, rien de plus étroit qu'un int est converti en int lors de l'utilisation de ce comme un argument de fonction. Qui peut faire partie de l'explication.

    • Une autre mauvaise "réponse". Conversion automatique de char à int rendrait tout inutile pour les constantes de caractère à ints. Ce qui est significatif, c'est que la langue traite des constantes de caractère différemment (en leur donnant un autre type) de char variables, et ce qui est nécessaire est une explication de cette différence.
    • Merci pour l'explication que vous avez donné ci-dessous. Vous pourriez décrire votre explication plus en détail dans la réponse, là où il appartient, peut-être voté, et facilement visible par les visiteurs. Aussi, je n'ai jamais dit que j'avais une bonne réponse ici. Par conséquent, votre jugement de valeur n'est d'aucune aide.
    InformationsquelleAutor Blaisorblade
  12. 0

    Ce n'est tangentielle à la langue spec, mais dans le matériel du PROCESSEUR habituellement n'a qu'un seul registre de la taille -- 32 bits, disons -- et donc, chaque fois qu'il fonctionne en fait sur un char (par l'addition, la soustraction, ou le comparant) il y a une conversion implicite de type int lorsqu'il est chargé dans le registre. Le compilateur prend en charge correctement masquage et en déplaçant le nombre après chaque opération, de sorte que si vous ajouter, disons, 2 (unsigned char) 254, ça va enrouler autour de 0 au lieu de 256, mais à l'intérieur de la silicon c'est vraiment un int jusqu'à ce que vous enregistrer dans la mémoire.

    C'est en quelque sorte un universitaire point, parce que la langue pourrait avoir spécifié un 8 bits type de littéral de toute façon, mais dans ce cas, la langue spec arrive à refléter plus fidèlement ce que le CPU est vraiment en train de faire.

    (x86 wonks peut noter qu'il y a par exemple un natif addh op qui ajoute de la courte échelle registres en une seule étape, mais à l'intérieur du noyau RISC cela se traduit par deux étapes: ajouter les numéros, puis étendre signe, comme un ajout/extsh paire sur le PowerPC)

    • Encore une autre mauvaise réponse. Le problème ici, c'est pourquoi les chaînes de caractères et char les variables de types différents. Automatique de promotions, qui reflètent le matériel, ne sont pas pertinents, ils sont en fait des anti-pertinent, parce que char variables sont automatiquement promus donc c'est pas une raison pour les chaînes de caractères ne pas être de type char. La vraie raison est multi-octets littéraux, qui sont maintenant obsolètes.
    • Balter multi-octets littéraux ne sont pas obsolète du tout; il y a plusieurs octets Unicode et UTF caractères.
    • Nous parlons de plusieurs octets. personnage littéraux, pas de multi-octets string littéraux. N'essayez de faire attention.
    • Chrashworks a écrit caractères. Vous devriez avoir écrit que large les chaînes de caractères (dire à L') ne prennent plus les octets mais ne sont pas appelés multi-octets char littéraux. D'être moins arrogant qui pourrait vous aider à être plus précis à vous-même.
    • Large les chaînes de caractères ne sont pas pertinentes ici, ils n'ont rien à voir avec ce que j'ai écrit. J'ai été précis et vous manque de compréhension et de votre bidon pour tenter de corriger moi est ce qu'il est arrogant.
    • Deux questions: 1) que la mention de l'UTF se référant à l'UTF-8? 2) Est-il impossible/obsolète pour encoder un seul non-ASCII, UTF-8 caractère multi-octets de caractères littérale? Si la réponse aux deux questions est oui, car il me semble (peut pas trouver des réponses définitives sur soit), je vous dois quelques excuses pour l'interroger votre précision.

    InformationsquelleAutor Crashworks