Discussion :

[Obsidian]

je me demande si bool c'est du C?

C'est du C99 : http://nicolasj.developpez.com/articles/c99/#LV-E

[lilington]

merci pour l'info du coup je comprend mieu pourquoi je voyais des BOOL et des bool.
donc si je ne me trompe pas BOOL c'est C++ et bool c'est C ?
bref jamais utilise car ignorant que ca existais en C je preferais utiliser 8bit (char) pour mes bool

[Obsidian]

donc si je ne me trompe pas BOOL c'est C++ et bool c'est C ? bref jamais utilise car ignorant que ca existais en C je preferais utiliser 8bit (char) pour mes bool

Non, je crois que c'est « bool » dans les deux cas. C'est juste que C99 en a profité pour normaliser pas mal de goodies introduites par le C++, comme les commentaires sur une seule ligne « // ».

[Melem]

Pour compléter, BOOL c'est généralement un typedef largement utilisé dans de nombreuses bibliothèques. Dans l'API Windows par exemple, BOOL est un typedef de int (cf. windef.h).

[lilington]

Merci mais bon deja c'est pas un type generique,
j'ai fait par defaut

Code :

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

bool b=false;

erreur de compilation,donc j'ai vu qu'il fallait inclure un truc, (GCC)
mais ca ca marche:

Code :

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

_Bool b;

sans rien avoir a inclure.

Pour compléter, BOOL c'est généralement un typedef largement utilisé dans de nombreuses bibliothèques. Dans l'API Windows par exemple, BOOL est un typedef de int (cf. windef.h).

dans ce cas je continue avec mes unsigned char drp =0 ou = 1 pour representer mes bools car faire appelle a un int n'est en rien plus economique qu'un uchar.

[Melem]

Merci mais bon deja c'est pas un type generique,
j'ai fait par defaut

Code :

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

bool b=false;

erreur de compilation,donc j'ai vu qu'il fallait inclure un truc, (GCC)
mais ca ca marche:

Code :

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

_Bool b;

sans rien avoir a inclure.

C'est pas sympa d'ignorer les liens que les gens te donnent. Le contenu était ceci :

Un booléen est un nouveau type de variable qui peut prendre uniquement la valeur vrai ou faux. La définition du type bool est faite dans le fichier d'en-tête stdbool.h et contient les définitions suivantes :

• bool : le type booléen
• true : la valeur vrai
• false : la valeur faux
• __bool_true_false_are_defined : si cette macro est définie, les valeurs bool, true et false le sont aussi.

La définition du type bool a été placée dans un fichier d'en-tête pour garantir la compatibilité avec les anciens codes (il n'est pas rare de voir un code contenant déjà une définition de bool). Si, pour une raison quelconque, vous ne souhaitez pas inclure stdbool.h, le langage contient le type _Bool qui peut prendre les valeurs 0 (faux) et 1 (vrai).

Pour compléter, BOOL c'est généralement un typedef largement utilisé dans de nombreuses bibliothèques. Dans l'API Windows par exemple, BOOL est un typedef de int (cf. windef.h).

dans ce cas je continue avec mes unsigned char drp =0 ou = 1 pour representer mes bools car faire appelle a un int n'est en rien plus economique qu'un uchar.

Dans ce cas, je t'encourage aussi à utiliser les champs de bits partout dans tes programmes, à chaque fois que c'est avantageux. Tes variables booléennes par exemple ne prendront plus qu'un bit et pas plus en mémoire, c'est encore plus économique non ?

Bon, revenons au vrai problème : est-ce que char est vraiment plus économique que int ? Pour répondre à cela, supposons que nous sommes sur une architecture PC où un char = 8 bits et int = 32 bits.

1. Dans de nombreux cas, les plus fréquents en plus, l'utilisation de char à la place de int ne réduit pas la mémoire utilisée par le programme, à cause des contraintes d'alignement. Par exemple, les fonctions suivantes requièrent la même quantité de mémoire à l'exécution :

Code :

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

1
2
3
4
5
6
int f_version_char_1(char c)
{
    int n;
    n = c;
    return n;
}

Code :

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

1
2
3
4
5
6
int f_version_int_1(int c)
{
    int n;
    n = c;
    return n;
}

Code :

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

1
2
3
4
5
6
7
int f_version_char_2(void)
{
    int n;
    char c = 1;
    n = c;
    return n;
}

Code :

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

1
2
3
4
5
6
7
int f_version_int_2(void)
{
    int n;
    int c = 1;
    n = c;
    return n;
}

En effet, dans tous les cas, c est empilé avant n mais à cause des contraintes d'alignement, n doit se localiser à une adresse multiple de 4, donc le fait d'avoir utilisé char à la place de int pour c ne nous fait pas gagner le moindre octet. Au contraire, en utilisant int au lieu de char, nous gérons mieux la mémoire.

Autre exemple, retourner un char au lieu d'un int n'économise rien du tout.

Bon, je me limiterai à ces quelques exemples.

2. Les opérations sur des int s'exécutent plus vite que les opérations sur des char. Cela signifie que l'instruction a = b && c; par exemple s'exécutera plus vite si a, b et c sont des int que si elles étaient des char. En effet dans la pratique, le type int correspond au type entier natif du processeur, c'est-à-dire le type entier avec lequel le processeur travaille avec sa performance maximale.

En outre, en langage C, les expressions logiques sont réellement de type int. Pas char ni unsigned char ni _Bool mais int. Par exemple, ('A' == 'a'), (11 != 20) et (0.5 > 1.0) sont des expressions de type int. Leurs valeurs respectives sont 0, 1 et 0. Ainsi, utiliser int pour représenter une expression ou une valeur booléenne est vraiment tout sauf farfelu ou bizarre.

Cela dit, la taille du type _Bool du C99 est généralement de 1 byte, bien que la norme ne l'impose pas. Byte ou int pour une variable booléenne n'est pas une question à laquelle on peut trancher de manière catégorique. Tout dépend des contraintes et des objectifs que l'on se fixe. Personnellement, lorsqu'on hésite, je recommande tout simplement d'utiliser int.