Discussion :

[JolyLoic]

Le type bool existe vraiment, car on peut écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void f(bool b) {}
void f(int i) {}
void f(char c) {}
void f(n'importe quoi d'autre) {}

alors que si bool était un simple typedef vers un un autre type, cette surcharge ne serait pas permise.

Donc, ça change les choses par ailleurs.

Par contre, bool ne fait pas 1 bit, mais je ne vois pas en quoi ça a le moindre rapport avec le fait qu'il soit un type ou pas. Après tout, double est bien un type, mais demande plus d'1 bit de stockage.

[Flob90]

<HS>
@ Pierre Dolez : Qu'est ce qui empêche de créer un type booléen qui ne prendrait qu'un bit ? C'est un problème technique (hardware) ou juste une convention comme quoi la plus petite unité est l'octet ?
</HS>

[Jean-Marc.Bourguet]

Si le type booléen existait réellement, chaque valeur d'une variable déclarée bool ne prendrait que 1 bit.

Pourquoi?

C'est quoi un type pour toi?

[jblecanard]

<HS>
@ Pierre Dolez : Qu'est ce qui empêche de créer un type booléen qui ne prendrait qu'un bit ? C'est un problème technique (hardware) ou juste une convention comme quoi la plus petite unité est l'octet ?
</HS>

C'est complètement hardware. Les registres, le séquenceur et l'unité de calcul des processeurs ne sont pas conçus pour gérer une granularité inférieure à l'octet.

[Jean-Marc.Bourguet]

<HS>
@ Pierre Dolez : Qu'est ce qui empêche de créer un type booléen qui ne prendrait qu'un bit ? C'est un problème technique (hardware) ou juste une convention comme quoi la plus petite unité est l'octet ?
</HS>

En C et en C++, un type a une taille qui est un nombre entier de bytes.

C'est complètement hardware. Les registres, le séquenceur et l'unité de calcul des processeurs ne sont pas conçus pour gérer une granularité inférieure à l'octet.

Quel est le probleme? Il y a des langages -- Ada par exemple -- qui gere parfaitement ce genre de situations. Une generalisation des bitfields de C et de C++ en quelque sorte.

[jblecanard]

Quel est le probleme? Il y a des langages -- Ada par exemple -- qui gere parfaitement ce genre de situations. Une generalisation des bitfields de C et de C++ en quelque sorte.

Tu peux t'amuser à stocker plusieurs booléens sur un même octet, mais tu gères toi même la notion de bitfield, ce n'est pas le processeur qui le fait. Rendre le stockage des types bool répartis sur des bitfields est possible, mais c'est une opération de trop haut niveau par rapport à C++. Et ça devient même carrément casse tête par rapport à la libération de la mémoire, etc...

Bref c'est 100 fois plus simple pour le compilo de prendre un octet et de pas s'emmerder.

[Flob90]

Mais si je fais un vector<bool> de taille 1, j'ai bien un bool stocké sur un seul bit, il gère ca comment ? Il reserve un octet et n'en utilise qu'un seul bit ?

[jblecanard]

Mais si je fais un vector<bool> de taille 1, j'ai bien un octet stocké sur un seul bit, il gère ca comment ? Il reserve un octet et n'en utilise qu'un seul bit ?

Un bit stocké sur un octet . Oui c'est ça, il utilise un octet complet. Après si tu veux gérer un grand nombre de booléens, c'est mieux d'utiliser des bitfields. Mais sinon franchement on s'en fout, vu la complexité des applis modernes et la puissance de nos machines, on va pas chouiner pour quelques octets.

Edit : c'est aussi là au cas ou vous douteriez des mes dires.

[Flob90]

J'ai édité, je voulais dire "un bool stocké sur un bit". bitfields et std::vector<bool>, ont pas la même utilité de tout façon, même si le stockage est le même.

Edit: Je ne doute pas, je sais que c'est la même taille, me demandait seulement pourquoi ce n'était pas su un seul bit

[jblecanard]

Pardon pour ma formulation, je voulais juste appuyer mes propos par un lien .

Au niveau de l'adressage mémoire, on ne peut pas descendre en dessous de l'octet. Il paraît que certains compilos gèrent les booléens sur des bitfields automatiquement, mais je n'arrive pas à trouver d'exemple...

[Jean-Marc.Bourguet]

Tu peux t'amuser à stocker plusieurs booléens sur un même octet, mais tu gères toi même la notion de bitfield, ce n'est pas le processeur qui le fait. Rendre le stockage des types bool répartis sur des bitfields est possible, mais c'est une opération de trop haut niveau par rapport à C++.

On est d'accord que le modele du C++ ne le permet pas.

Mais ce n'est pas qqch d'intrinseque, ni a la notion de type, ni au hard.

(En passant, il y a des processeurs qui permettent de manipuler les bits individuellements, et le faire pour un processeur qui ne le permet pas est d'une complexite nettement moindre que gerer les exceptions).

Et ça devient même carrément casse tête par rapport à la libération de la mémoire, etc...

Je ne vois pas de problemes. Les allocateurs fonctionnent deja avec des unites nettement plus grande qu'un byte.

[Invité]

Bonjour JoliLoic,

Le type bool existe vraiment, car on peut écrire :
Code :

void f(bool b) {}
void f(int i) {}
void f(char c) {}
void f(n'importe quoi d'autre) {}


alors que si bool était un simple typedef vers un un autre type, cette surcharge ne serait pas permise.

Mon compilateur l'accepte très bien:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
typedef char NBOOL;
void foo(NBOOL b){return;}
int main(int argc, char* argv[])
{
foo('a');
}

En C++ bool n'est pas un typedef, mais un mot-clé.

[Goten]

Y'a pas de surcharge là...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
typedef char NBOOL;
 
void foo(NBOOL){}
void foo(char) {}
 
int main()
{
  foo('a');
}

c'est ça que mettait en avant Loic. Et oui bool n'est pas un typedef, bool est un type primitif au même titre que int etc

Et histoire de pas parler dans le vide :

norme p3.9.1 :

6. Values of type bool are either true or false.42) [Note: there are no signed, unsigned, short, or
long bool types or values. ] As described below, bool values behave as integral types. Values of type
bool participate in integral promotions (4.5).
7. Types bool, char, wchar_t, and the signed and unsigned integer types are collectively called integral
types.

[jblecanard]

(En passant, il y a des processeurs qui permettent de manipuler les bits individuellements, et le faire pour un processeur qui ne le permet pas est d'une complexite nettement moindre que gerer les exceptions).

Comme le dit si bien le type sur StackOverflow, c'est un compromis entre mémoire utilisée et perfos. C'est plus rapide de prendre un octet complet et de n'utiliser qu'un bit que de faire des calculs avec des décalages de bits.

Je ne vois pas de problemes. Les allocateurs fonctionnent deja avec des unites nettement plus grande qu'un byte.

Je ne vois pas le rapport, puisqu'on parle de descendre en dessous du byte .

Plus sérieusement, le fait que l'allocateur alloue de base beaucoup plus qu'un octet est géré par l'OS donc à un autre niveau. Maintenant imagine que tu écris ton compilateur. A chaque nouveau booléen, il faut aller le mettre dans un octet ou il y a "encore de la place". Et quand tu le détruis, il faut vérifier que l'octet ne contient pas d'autres booléens qui ne doivent pas être détruit, etc... Bref c'est assez complexe ! Alors que prendre un octet et le détruire au moment de détruire le booléen, et bah c'est tout simple.

J'ai comme l'impression qu'on est en train de sombrer tout droit dans le hors sujet là

[Jean-Marc.Bourguet]

Je ne suis pas tout à fait d'accord : c'est intrinsèque au hard dans une grande majorité d'architecture. Tu ne peux pas adresser de zone mémoire plus petite que un octet sur ton pc ou ton mac.

Pas plus que tu ne peux adresser des zones plus grande que 16, 18, 32, 36, 64, 80 ou 128 bits. Ca n'empeche pas les compilateurs de fournir ce qu'il faut quand c'est utile.

Comme le dit si bien le type sur StackOverflow, c'est un compromis entre mémoire utilisée et perfos. C'est plus rapide de prendre un octet complet et de n'utiliser qu'un bit que se faire des calculs avec des décalages de bits.

Tu me permettras de ne pas etre d'accord? La raison indiscutable pour laquelle les bool font (au minimum) 1 byte en C++, c'est que le modele du C++ ne permet pas des types plus petits et que quand on a introduit les bool, celui-ci etait deja suffisamment etabli pour que le modifier n'etait pas envisageable.

On peut considerer que meme si ca avait ete envisageable, le resultat n'aurait pas ete change parce que c'est un bon compromis. Le point de vue se tient mais ca me semble pas si certain que cela.

Je ne vois pas le rapport, puisqu'on parle de descendre en dessous du byte .

Tu dis que gerer des bits serait infernal dans les allocateurs. Je te dis que je ne vois pas pourquoi ils auraient a faire autre chose pour les bits que ce qui est deja fait pour les bytes: arrondir a une unite superieure gerable.

Plus sérieusement, imagine que tu écris ton compilateur.

Been there, done that.

A chaque nouveau booléen, il faut aller le mettre dans un octet ou il y a "encore de la place". Et quand tu le détruis, il faut vérifier que l'octet ne contient pas d'autres booléens qui ne doivent pas être détruit, etc... Bref c'est assez complexe !

Je ne vois pas en quoi c'est complexe. Il n'y a rien a faire pour detruire un bool. Il ne faut s'occuper que de l'allocation de la memoire. On a simplement un type avec des contraintes d'alignement differentes et on gere ca comme on gere les types actuels avec leurs contraintes d'alignement. (Note que j'envisagerais d'aligner les bool sur les bytes en dehors des tableaux -- un autre compromis qui serait rendu possible en ayant des bools ayant une taille de 1 bit).

Alors que prendre un octet et le détruire au moment de détruire le booléen, et bah c'est tout simple.

C'est quoi detruire un octet?

[bacelar]

Dites donc, ça fait un bon bout de temps que vous n’avez pas vu du code assembleur ou quoi ?

Les opcodes utilisant les registres de flags, qui font tous un bit, pullulent sur les CPU x86 (même en 64 bits avec ligne de cache 256 bytes et mode burst).

Un bit c'est un bit, pas un byte camouflé.

P.S.: bool est un type primitif ET un mot réservé du C++ (comme int ...).

[jblecanard]

Tu me permettras de ne pas etre d'accord? La raison indiscutable pour laquelle les bool font (au minimum) 1 byte en C++, c'est que le modele du C++ ne permet pas des types plus petits et que quand on a introduit les bool, celui-ci etait deja suffisamment etabli pour que le modifier n'etait pas envisageable.

On peut considerer que meme si ca avait ete envisageable, le resultat n'aurait pas ete change parce que c'est un bon compromis. Le point de vue se tient mais ca me semble pas si certain que cela.

C'est donc surtout historique, intéressant .

C'est quoi detruire un octet?

Libérer la mémoire, s'entend. Mais il est vrai que le problème est exactement le même quand tu adresse des zones mémoires plus grande qu'un octet et que tu y stockes des char. J'ai trop souvent tendance à vouloir imaginer l'assembleur qui sort derrière le C++ que j'écris, et je pense avec des simples registres 8 bits exclusivement >_<.

Dites donc, ça fait un bon bout de temps que vous n’avez pas vu du code assembleur ou quoi ?

Force est de constater que oui pour ma part.

Les opcodes utilisant les registres de flags, qui font tous un bit, pullulent sur les CPU x86 (même en 64 bits avec ligne de cache 256 bytes et mode burst).

Un bit c'est un bit, pas un byte camouflé.

Mais il reste vrai que le booléen de C++ est un byte

[Luc Hermitte]

Je ne vois pas le rapport entre la taille de bool en C++ et le reste.
int, short et long peuvent avoir la même taille, et pourtant il s'agit de trois types, et non seulement de mot clés. Pourquoi chercher à faire une exception avec bool?

[white_tentacle]

Tu me permettras de ne pas etre d'accord? La raison indiscutable pour laquelle les bool font (au minimum) 1 byte en C++, c'est que le modele du C++ ne permet pas des types plus petits et que quand on a introduit les bool, celui-ci etait deja suffisamment etabli pour que le modifier n'etait pas envisageable.

Est-ce le modèle du C++ ou celui des architectures sur lesquelles il tourne en général ?

Parce que si bool prend 1 unique bit, comment est défini bool* ?

Il me semble qu'avoir un type qui tienne moins en mémoire que l'unité de l'espace d'adressage est très problématique dans un langage à pointeurs. Ou alors tu englobes ça dans le "modele du C++" ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
struct pair_bool
{
    bool b1; // 1 bit
    bool b2; // 1 bit
} // pair_bool fait 2 bits, donc sizeof(pair_bool) == 1 byte
 
void fail()
{
    pair_bool b;
    b.b1 = true;
    b.b2 = false;
    bool* pb = &b.b2; // que vaut pb si sizeof(pair_bool) == 1 ?
}

[white_tentacle]

Mais il reste vrai que le booléen de C++ est un byte

Non, par exemple, std::vector<bool> est justement spécialisé pour les gérer en tant que bit unitaires.