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...

[Melem]

Il est judicieux (avis personnel) de se forcer à écrire: if(x == 0) ... si x a une sémantique d'entier ...

Code :

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

if (strlen(s))

se lit sans problème : si s a une longueur, autrement dit : si la longueur de s est > 0 soit if (strlen(s) > 0)

Code :

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

while (s[i])

se lit sans problème : tant que s[i] a un sens, autrement dit : tant que s[i] != '\0'

...

[Melem]

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 fonctionne 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 ?

La valeur de retour d'une fonction permet de savoir si elle s'est bien déroulée. En C on a l'habitude de retourner un int même dans des cas où on n'a pas vraiment quelque chose à retourner. On retourne 0 quand tout s'est bien passé et une valeur différente pour dire qu'il y a eu une erreur.

Cependant certaines fonctions, comme certaines APIs de Windows par exemple, retournent un BOOL (qui n'est autre qu'un int) au lieu d'un int . Ces fonctions retournent TRUE (1) lorsque tout s'est bien passé et FALSE (0) en cas d'erreur. Tu peux utiliser cette convention si ça te chante ...

[Médinoc]

Pardon, la doc des fonctions BOOL de Windows garantit que les fonctions retournent UNE VALEUR NON-NULLE en cas de succès (même si la doc de certaines fonctions a évolué et s'est restreinte à TRUE et FALSE).

Je ne vois pas pourquoi tu te marres sur "BOOL": Ça permet du premier coup d'oeil de voir que ces fonctions n'ont pas la convention de retour POSIX, ce qui serait source de nombre de confusions si elles retournaient simplement un int...

Et de toute façon, un vrai programmeur Windows utilise (et programme) des fonctions qui retournent un HRESULT et non un BOOL...

[Melem]

Pardon, la doc des fonctions BOOL de Windows garantit que les fonctions retournent UNE VALEUR NON-NULLE en cas de succès (même si la doc de certaines fonctions a évolué et s'est restreinte à TRUE et FALSE).

Mais justement, une valeur non nulle signifie VRAI (TRUE en anglais ). Bon c'est vrai que TRUE est défini comme étant égal à 1 si je ne me trompe, mais en tout cas je ne crois pas que quelqu'un puisse être assez ouf pour écrire if (... == TRUE)

Je ne vois pas pourquoi tu te marres sur "BOOL": Ça permet du premier coup d'oeil de voir que ces fonctions n'ont pas la convention de retour POSIX, ce qui serait source de nombre de confusions si elles retournaient simplement un int...

Et de toute façon, un vrai programmeur Windows utilise (et programme) des fonctions qui retournent un HRESULT et non un BOOL...

Le thème c'est sur les booléens non?

[Médinoc]

Mais justement, une valeur non nulle signifie VRAI (TRUE en anglais ). Bon c'est vrai que TRUE est défini comme étant égal à 1 si je ne me trompe, mais en tout cas je ne crois pas que quelqu'un puisse être assez ouf pour écrire if (... == TRUE)

Tu seras surpris de voir à quel point on peut être "ouf". Dans ce genre de cas, il vaut mieux préciser...

[Sve@r]

Code :

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

while (s[i])

se lit sans problème : tant que s[i] a un sens, autrement dit : tant que s[i] != '\0'

...

Et si un jour le caractère de fin de chaîne change ??? Bon je sais que je prends un exemple extrèmement improbable mais malgré tout je suis plutôt d'accord avec Pierre Maurette. Même si

Code :

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

if (strlen(s))

se lit parfaitement pour qui est habitué du C, ce n'est pas un trop lourd boulot d'écrire à la place

Code :

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

if (strlen(s) > 0)

1) ça a le mérite d'être au-moins aussi parlant que l'écriture précédente
2) ça a le mérite de ne pas déstabiliser aussi peu que ce soit un débutant qui viendrait à passer par là et qui risquerait d'être à jamais dégoûté du C
3) ça a le mérite d'être plus facilement portable dans d'autres langages qui n'auraient pas la même conception du vrai/faux

Je préfère donc écrire

Code :

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

if (s[i] != '\0')

qui signifie littéralement "si le caractère n'est pas égal au marqueur de fin" et qui correspond plus à l'idée que je me fais d'un algo de balayage de chaîne. Faut se méfier de l'attitude qui consiste à dire "boaf tout le monde comprendra". Avec un peu de laisser aller ça amène ensuite à écrire des trucs de ce style

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
#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}

...

[Melem]

Je suis très pour lisibilité mais ce que je veux dire c'est que ce que l'on qualifie parfois d'illisible ne l'est pas vraiment, comme les exemples ci-dessus. D'ailleurs l'objectif c'est de pouvoir écrire du code compact (et rapide), par exemple

Code :

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

1
2
3
4
5
 
void str_cpy(char * dest, char * src)
{
    while (*dest++ = *src++);
}

Ce genre de code ca va très vite. J'espère seulement que le caractère de fin de chaîne est encore '\0'.

[Thierry Chappuis]

Je suis peut-être vieux jeu, mais je préfère écrire:

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
char * str_cpy(char *dest, char const *src)
{
    char *p_ret = NULL;
 
    if (dest != NULL && src != NULL)
    {
        while (*src != 0)
        {
            *dest = *src;
            dest++;
            src++;
        }
        *dest = 0;
        p_ret = dest;
    }
 
    return p_ret;
}

J'ai confiance que mon compilo se débrouillera au mieux pour l'optimisation. D'autre part, c'est pas parce que le code est compact et que c'est rapide à écrire que le code généré l'est pour autant. Aussi, à la vérification de la validité des arguments prête, je ne suis pas persuadé que ton code est tellement plus rapide que le miens.

Thierry

[Melem]

Je pense que tout dépend du contexte, parfois du code trop décompacté devient plus difficile à lire, notamment à cause de la longueur.

D'autre part, c'est pas parce que le code est compact et que c'est rapide à écrire que le code généré l'est pour autant.

Je n'ai jamais affirmé de pareille bétise, néanmoins je suis sûr (bien que j'ai pas compilé pour voir) que mon code est plus rapide que le tiens, c'est une certitude.

[Thierry Chappuis]

Je pense que tout dépend du contexte, parfois du code trop décompacté devient plus difficile à lire, notamment à cause de la longueur.
Je n'ai jamais affirmé de pareille bétise, néanmoins je suis sûr (bien que j'ai pas compilé pour voir) que mon code est plus rapide que le tiens, c'est une certitude.

Si j'enlève le test de la validité des arguments, les différences au niveau du code généré ne sont pas si importantes que cela.

Thierry

[Emmanuel Delahaye]

Jnéanmoins je suis sûr (bien que j'ai pas compilé pour voir) que mon code est plus rapide que le tiens, c'est une certitude.

Il ne faut rien affirmer tant qu'on a pas :

- Comparé le code généré.
- Fait des mesures dans des conditions définies et reproductibles.

[Pierre Maurette]

Mais justement, une valeur non nulle signifie VRAI (TRUE en anglais ). Bon c'est vrai que TRUE est défini comme étant égal à 1 si je ne me trompe, mais en tout cas je ne crois pas que quelqu'un puisse être assez ouf pour écrire if (... == TRUE)
Le thème c'est sur les booléens non?

Oui, au départ. Il faudrait préciser quelques trucs, ça ne semble pas encore tout à fait clair.

Valable que ce soit en C99 ou en C pré99:

- Le résultat d'un opérateur relationnel ou logique, ==, !=, <, >, <=, >=, &&, ||, ! est de type int et vaut soit 0 soit 1, exclusivement. Les opérateurs bitwise n'entrent pas en ligne de compte dans cette conversation, ce sont des opérateurs arithmétiques à mon sens, même s'ils sont un peu pollués pour des raisons historiques.

- Pour les opérateurs &&, || et !, dans exp1 && exp2, exp1 || exp2, !exp1, exp1 et exp2 doivent être d'un type scalar. C'est à dire entier, flottant ou pointeur. Ils sont traités comme faux s'ils sont "comparé égaux à 0". Comme vrai dans tous les autres cas.

Ainsi !!x vaut (int)0 si x vaut 0, (void*)0 ou 0.0, (int)1 dans tous les autres cas.

Pour le type bool, c'est une autre affaire. Il existe bien qu'un peu boiteux en C++. C'est un vrai type booléen en ce sens qu'il ne peut prendre que deux valeurs, mais le poids de l'héritage du C est grand. Enfin, je peux me tromper sur le C++.
Il faut bien voir que seul un type natif peut avoir un vrai comportement de booléen, tel qu'on est en droit de l'attendre. Ou alors il faut fabriquer une classe, ou en C s'en approcher.
Un vrai comportement de booléen, c'est ne pouvoir appliquer que des opérateurs logiques, et/ou définir clairement (tables de vérité) les autres opérateurs, de façon cohérente avec nos cours de maths.
Toutes les rustines à base de typedef ou d'enum fonctionnent peu ou prou, pour peu qu'on s'impose des précautions. Mais elles contiennent des dangers, autour du fait de pouvoir se convertir en autre chose que 0 ou 1, et que cet autre chose fera que la comparaison de deux valeurs "différentes de 0" ne sera pas correcte.
C99 contient un tel type natif, c'est _Bool. Dans <stdbool.h>, on a un typedef de bool à _Bool. Je ne pense pas qu'une implémentation prétendument C99 qui se contenterait de typedef-er bool à int dans <stdbool.h> serait valide.
Edit: j'oubliais de préciser que dans un programme qui traiterait d'automatisme par exemple, il est impératif de pouvoir comparer simplement l'état de deux interrupeurs, voir de comparer l'état d'un interrupteur à true.