Discussion :

[Panaméen]

voila tout est dans le titre
mon prof m'a dit que souvent en C on "testait la fonction " en lui faisant retourner un booleen pour voir si elle fonctione correctement

il ne sait pas etaler dessus cest pourquoi je vous demande ca , l'utilité ... ? et comment on sent sert , je sais deja faire une énum ...

en fait , jai declaré l'enum dans le main ( ) ... or je ne vois pas comment creer une variable de type booleen dans la fonction ?

faut il mettre l'enumeration en globale ?

[LinuxUser]

Peut-tu expliquer un peu mieux ce que tu souhaite faire.
Au sujet des booléen soit tu renvoi 0 ou 1 ou si tu veux vraiment tu peux faire une structure bool avec un champ entier.

[PsychoH13]

Déjà oui les définitions/déclarations de types doivent être globales.
Ensuite, les booléens sont des variables qui prennent deux valeurs VRAI ou FAUX, en C, par défaut, ça n'existe pas, cependant ils existent implicitement, en général on les remplace par des int, quand c'est égal à 0 c'est FAUX quand c'est différent de 0 c'est VRAI (en général 1).

Les booléens permettent par exemple de dire si une fonction s'est bien exécutée. Ça te permet aussi de vérifier l'égalité, genre quand t'écris if(a == b) c'est un booléen que tu testes.

Sinon voilà comment on définit le booléen :

Code :

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

1
2
3
4
typedef enum Boolean {
    FALSE,
    TRUE
} Boolean;

Et dans ton code tu peux écrire :

Code :

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

Boolean monBouleen;

Ou encore le mettre comme valeur de retour d'une fonction :

Code :

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

Boolean f()

ou comme paramètre:

Code :

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

void f(Boolean flag);

[Pierre Maurette]

voila tout est dans le titre
mon prof m'a dit que souvent en C on "testait la fonction " en lui faisant retourner un booleen pour voir si elle fonctione correctement

Soyons clairs: c'est vous, le programeur, qui déciderez de renvoyer "bon" ou "pas bon" selon ce que la fonction aura pu faire. Rien de magique, rien qui vous dira par enchantement que la fonction "a fonctionné correctement". Je suppose que j'enfonce des portes ouvertes, mais autant être précis.

il ne sait pas etaler dessus cest pourquoi je vous demande ca , l'utilité ... ? et comment on sent sert , je sais deja faire une énum ...

en fait , jai declaré l'enum dans le main ( ) ... or je ne vois pas comment creer une variable de type booleen dans la fonction ?

faut il mettre l'enumeration en globale ?

Jusqu'en C99 (en C pré-99), il n'y avait pas de type booléen en C, et on s'en passait très bien[*]. Un booléen, au sens de "un truc vrai ou faux", était stocké dans un int. Lors d'un test, une valeur de 0 était lue comme FAUX, toute autre valeur était lue comme VRAI. A l'inverse, une expression visiblement booléenne, comme a == b, c > 10, etc. est évaluée à 0 si elle est FAUX, à 1 (garanti, pas autre chose) si elle est VRAI.
Un booléen devait être caractérisé par un nommage correct. "isValid" par exemple, ou "fini" dans une boucle, sont des noms d'entiers à sémantique booléenne. A partir du moment où un entier devient un booléen, il faut impérativement par des règles de programmation non vérifiées par le compilateur s'interdire des opérations, arithmétiques en particulier, qui n'ont pas de sens pour un booléen. Il est judicieux (avis personnel) de se forcer à écrire: if(x == 0) et if(condition) si x a une sémantique d'entier et condition une sémantique de booléen.
En C99, norme qui va doucettement vers ses dix ans d'âge, il existe un type booléen. Il faut inclure <stdbool.h> pour utiliser bool, true et false.
Donc, c'est juste mon conseil, pour le reste faites ce qu'il faut pour faire plaisir à votre prof, soit vous utilisez des int avec les règles données ci-dessus, soit (et pourquoi ne le feriez-vous pas ?) vous inclurez <stdbool.h>. Si vous voulez absolument faire des enum à la mormwaldar, il faut les définir dans un .h, ou au même endroit que les #include<xxx.h>, en tête de chaque fichier qui utilise le type.
Un bon type booléen ne devrait jamais pouvoir prendre une "valeur" autre que 0 ou 1. Ce n'est pas le cas pour le int, mais surtout pour les types bricolés. Si vous avez un programme d'automatisme, par exemple, vous aurez alors un problème potentiel si vous testez l'égalité de l'état de deux "interrupteurs", tous deux à VRAI, qui peuvent être comparés différents. Donc, soit le vrai bool de C99, soit le int et les précautions.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
 
typedef enum {FALSE, TRUE} BOOL;
 
int divise1(int* dividende, int diviseur){
	int possible = (diviseur != 0);
	if(possible){
		*dividende /= diviseur;
	}
	return possible;
}
 
int divise2(int* dividende, int diviseur){
	int impossible = (diviseur == 0);
	if(!impossible){
		*dividende /= diviseur;
	}
	return !impossible;
}
 
bool divise3(int* dividende, int diviseur){
	bool impossible = (diviseur == 0);
	if(!impossible){
		*dividende /= diviseur;
	}
	return !impossible;
}
 
bool divise4(int* dividende, int diviseur){
	bool impossible = (diviseur == 0);
	if(!impossible){
		*dividende /= diviseur;
	}
	return !impossible;
}
 
 
int main(void) {
	int a = 10, b= 2;
	if(divise1(&a, b)){
		printf("resultat: %d\n", a);
	}
	else{
		printf("Division par 0, %d\n", a);
	}
	int x = (1 == 1);
	bool y = (1 == 1);
	BOOL z = (1 == 1);
	x *= 3;
	y *= 3;
	z *= 3;
	printf("%d\t%d\t%d\n", x, y, z);
	printf("%d\t%d\t%d\n", !!x, !!y, !!z);
	return (0);
}

[*]En fait, pas si bien que ça, un vrai type booléen aurait été une bonne chose...

[c-candide]

A partir du moment où un entier devient un booléen, il faut impérativement par des règles de programmation non vérifiées par le compilateur s'interdire des opérations, arithmétiques en particulier, qui n'ont pas de sens pour un booléen.

impérativement, comme tu y vas fort. Un exemple, même s'il est un peu tiré par les cheveux :

Code :

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

1
2
 
int ValAbs(int x){return ((x>0)-(x<0))*x;}

Sinon, x est un booléen, 1-x en est encore un. Et puis en faisant des opérations arithmétiques modulo 2, on exprime ainsi très simplement les opérations logiques élémentaires comme la conjonction p && q en p*q, le ou exclusif (p XOR q) en p+q. Si on a trois ou plus variables booléennes, ça pourrait être plus simple de passer par des expressions arithmétiques.

Code :

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

1
2
3
4
5
#include <stdio.h>
 
int divise2(int* dividende, int diviseur)
 
etc.

Quel est l'intérêt des fonctions divisek où k>1 ?

[Pierre Maurette]

impérativement, comme tu y vas fort. Un exemple, même s'il est un peu tiré par les cheveux :

Code :

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

1
2
 
int ValAbs(int x){return ((x>0)-(x<0))*x;}

Sinon, x est un booléen, 1-x en est encore un.

Non. Ici x est un int. Et (x>0) est le résultat de l'opérateur >, c'est à dire 1 ou 0, de type int. Donc il n'y a pas contradiction avec ce que j'écrivais, la méthode est valide et pourrait avoir un intérêt, par exemple pour espérer un code sans branches. J'écris bien "espérer", parce que le compilateur génère ce qu'il veut.

Et puis en faisant des opérations arithmétiques modulo 2, on exprime ainsi très simplement les opérations logiques élémentaires comme la conjonction p && q en p*q, le ou exclusif (p XOR q) en p+q. Si on a trois ou plus variables booléennes, ça pourrait être plus simple de passer par des expressions arithmétiques.

Si vous voulez vous pouvez utiliser ça protégé dans une fonction, qui prend des int à sémantique booléenne et renvoie un booléen à sémantique booléenne. Mais je maintiens mon conseil. Si une variable int à sémantique booléenne vient à prendre la valeur 2, ou -1 (dans les deux cas elle sera à VRAI), (p + q) % 2 ne vous donnera pas le résultat attendu. Et si vous masquez dans une fonction ou une macro EXOR(a, b), autant écrire (a || b) && !(a && b).

Quel est l'intérêt des fonctions divisek où k>1 ?

C'était montrer avec int et bool que le nommage doit être conforme à la réalité, et qu'un code d'erreur doit correspondre à ce qui est normalement considéré comme une erreur (impossible, division par 0). Mais je n'ai pas terminé mon copié / collé pour le dernier, une erreur...

[diogene]

Pierre Maurette :

A partir du moment où un entier devient un booléen, il faut impérativement par des règles de programmation non vérifiées par le compilateur s'interdire des opérations, arithmétiques en particulier, qui n'ont pas de sens pour un booléen. Il est judicieux (avis personnel) de se forcer à écrire: if(x == 0) et if(condition) si x a une sémantique d'entier et condition une sémantique de booléen.

+1

Envoyé par c-candide
impérativement, comme tu y vas fort. Un exemple, même s'il est un peu tiré par les cheveux :

Code :

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

int ValAbs(int x){return ((x>0)-(x<0))*x;}

Je n'aime pas du tout ce genre d'écriture qui rappelle le jargonnage utilisé au temps héroïques où les programmeurs C aimaient rendre leur code illisible pour les autres.

[Emmanuel Delahaye]

Je n'aime pas du tout ce genre d'écriture qui rappelle le jargonnage utilisé au temps héroïques où les programmeurs C aimaient rendre leur code illisible pour les autres.

Jargonnage d'autre part tant décrié par Candide qui n'en rate pas une pour se contredire...