Pourquoi le sizeof (bool) n'est pas défini pour être un, par la norme elle-même?

Question

La taille de l' char, signed char et unsigned char est définie à 1 octet, par la Norme C++ lui-même. Je me demande pourquoi il n'a pas de définir l' sizeof(bool) aussi?

C++03 Standard de $5.3.3/1 dit,

sizeof(char), sizeof(char signé) et sizeof(unsigned char) sont 1; la résultat de sizeof appliquée à tout autre type fondamental (3.9.1) est la mise en œuvre définies. [Note: dans en particulier,sizeof(bool) et sizeof(wchar_t) sont la mise en œuvre définies par.69)

Je comprends la logique qui sizeof(bool) ne peut être inférieur à un octet. Mais est-il une raison pour laquelle il devrait être plus grand que 1 octet soit? Je ne dis pas que les implémentations de la définir à être plus grand que 1, mais la Norme de gauche à être défini par la mise en œuvre que si elle peut être supérieur à 1.

Si il n'y a pas de raison sizeof(bool) pour être plus grand que 1, je ne comprends pas pourquoi le Standard n'a pas la définir simplement comme de l' 1 byte, comme il l'a défini sizeof(char), et c'est toutes les variantes.

Answer 1

L'autre taille probable est que d' int, être "efficace" de type entier pour la plate-forme.

Sur les architectures où cela fait une différence si la mise en œuvre choisit 1 ou sizeof(int) il pourrait y avoir un compromis entre la taille (mais si vous êtes heureux de déchets de 7 bits par bool, pourquoi ne devriez-vous pas être heureux de déchets 31? Utilisation bitfields lorsque les sujets de taille) et de performances (mais quand c'est le stockage et le chargement des valeurs bool va être un véritable problème de performance? Utiliser int explicitement lorsque la vitesse de questions). Donc, la mise en œuvre de la flexibilité gagne - si, pour quelque raison, 1 serait atroce en termes de performances ou de la taille du code, il peut l'éviter.

Answer 2

Comme @MSalters souligné, certaines plates-formes de travail de manière plus efficace avec de plus grands éléments de données.

De nombreux "RISC" Cpu (par exemple, MIPS, PowerPC, les premières versions de l'Alpha) ont/ont eu beaucoup plus de difficulté à travailler avec des données plus petite qu'un mot, si ils font la même chose. IIRC, avec au moins certains compilateurs sur l'Alpha d'un bool réellement occupé 64 bits.

gcc pour les Mac à processeur PowerPC, par défaut, à l'aide de 4 octets pour un bool, mais a un switch pour modifier qu'à un seul octet, si vous vouliez.

Même pour le x86, il y a certains avantages à l'utilisation de données 32 bits élément. gcc pour le x86 a (ou au moins l'habitude d'avoir -- je n'ai pas regardé récemment à tous) une définition dans l'une de ses fichiers de configuration pour l' BOOL_TYPE_SIZE (de mémoire, si je pouvais avoir ce nom un peu mal) que vous pourriez mettre à 1 ou 4, et puis re-compiler le compilateur pour obtenir un bool de cette taille.

Edit: Comme pour la raison derrière cela, je dirais que c'est un simple reflet d'une philosophie de base de C et C++: laisser le plus de place pour la mise en œuvre pour optimiser/personnaliser son comportement raisonnable. Exiger un comportement spécifique seulement quand/si il y a une évidente, avantages tangibles, et peu de chances d'être toute grande responsabilité, surtout si le changement de la rendre beaucoup plus difficile sur le support C++ sur certaines plate-forme en particulier (même si, bien sûr, si la plate-forme est assez obscure, il peut être ignoré).

Answer 3

De nombreuses plates-formes ne peuvent pas charger efficacement des valeurs inférieures à 32 bits. Ils doivent charger 32 bits et utiliser une opération de décalage et de masquage pour extraire 8 bits. Vous ne voudriez pas cela pour le single bool s, mais c'est OK pour les chaînes.

Answer 4

L'opération a abouti à «sizeof» en MADU (unité minimale d'adressage), et non en octets. Donc, les processeurs de la famille C54 *. C55 * Texas Instuments, l'expression 1 MADU = 2 octets.

Pour cette plate-forme sizeof (bool) = sizeof (char) = 1 MADUs = 2 octets. Cela ne viole pas la norme C ++, mais clarifie la situation.