l'utilité d'utiliser les Booleens

Version imprimable

01/12/2007, 21h00
Panaméen

l'utilité d'utiliser les Booleens

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 ?
01/12/2007, 21h12
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.
01/12/2007, 21h19
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:

1 2 3 4 typedef enum Boolean { FALSE, TRUE } Boolean;
Et dans ton code tu peux écrire :

Code:

Boolean monBouleen;

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

Code:

Boolean f()

ou comme paramètre:

Code:

void f(Boolean flag);

Citation:

Envoyé par Pugebad

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.

Citation:

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:

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

02/12/2007, 02h25
c-candide
Citation:

Envoyé par 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.

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

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.
Citation:
Envoyé par Pierre Maurette

Code:

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 ?
02/12/2007, 09h16
Pierre Maurette
Citation:
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:

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.

Citation:

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

Citation:

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...
02/12/2007, 20h09
diogene

Pierre Maurette :

Citation:

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

Citation:

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:

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.
03/12/2007, 14h12
Emmanuel Delahaye

Citation:

Envoyé par diogene

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...
03/12/2007, 16h30
Melem

Citation:

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

Code:

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:

while (s[i])

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

...
03/12/2007, 16h39
Melem

Re:

Citation:

Envoyé par Pugebad

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 :mouarf:. 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 ...
03/12/2007, 23h47
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...:P
05/12/2007, 16h27
Melem

Citation:

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 :lol:). 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)

Citation:

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? ;)
05/12/2007, 21h45
Médinoc

Citation:

Envoyé par Melem

Mais justement, une valeur non nulle signifie VRAI (TRUE en anglais :lol:). 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...

Citation:

Envoyé par Melem

Code:

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:

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:

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:

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:

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() { _-_-_-_ _-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_ _-_-_-_ }
...

06/12/2007, 07h52
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:

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

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

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

06/12/2007, 09h09
Melem

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

Citation:

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.
06/12/2007, 09h40
Thierry Chappuis

Citation:

Envoyé par Melem

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
06/12/2007, 09h44
Emmanuel Delahaye

Citation:

Envoyé par Melem

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.
06/12/2007, 10h55
Pierre Maurette

Citation:

Envoyé par Melem

Mais justement, une valeur non nulle signifie VRAI (TRUE en anglais :lol:). 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.
06/12/2007, 14h03
souviron34

Citation:

Envoyé par Melem

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? ;)

tu as tort sur ce point...

Vu que tout dépend de la définition de la norme et, dans le cas où elle ne le précise pas, de la définition de l'implémentation, il se peut parfaitement que

TRUE soit définie
et FALSE soit NON TRUE

ou que

FALSE soit défini
et TRUE soit NON FALSE

et donc on peut avoir les 2 types de tests..

if ( ... == FALSE )

ou

if ( ..... == TRUE )

Comme dit plus haut, la seule chose en C est que la plupart des fonctions "standards" retournent 0 en cas d'échec, mais par exemple main() a la convention inverse....
06/12/2007, 14h14
Médinoc

Euh...
Quelle "plupart" exactement ?

Les fonctions d'entrées/sortie retournent généralement EOF sur un échec, malloc() ne retourne pas un entier mais un pointeur (donc le "0" a une toute autre signification)...
06/12/2007, 14h25
Melem

Citation:

Citation:

Envoyé par Melem

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?

tu as tort sur ce point...

Vu que tout dépend de la définition de la norme et, dans le cas où elle ne le précise pas, de la définition de l'implémentation, il se peut parfaitement que

TRUE soit définie
et FALSE soit NON TRUE

ou que

FALSE soit défini
et TRUE soit NON FALSE

et donc on peut avoir les 2 types de tests..

if ( ... == FALSE )

ou

if ( ..... == TRUE )

Peut importe la manière dont on a défini les macros TRUE et FALSE, il suffit de faire if (x) pour tester si x est VRAI ... On utilise généralement ces macros pour initialiser une variable ou pour affecter une valeur, pas dans les expressions de test.
06/12/2007, 14h29
PsychoH13

Exactement, soyons cohérent... Quand on souhaite utiliser des booléens, il faut utiliser l'algèbre booléennes : !, &&, ||, le reste n'a pas vraiment de sens.
06/12/2007, 20h26
Sve@r

Citation:

Envoyé par Melem

D'ailleurs l'objectif c'est de pouvoir écrire du code compact (et rapide)

Au débuts du C c'est ce que croyaient les programmeurs. A savoir que plus le code était compact et plus il était rapide.
Au fil du temps (et aussi avec l'optimisation des compilos), ils se sont rendus compte qu'un code compact n'était pas forcément plus rapide qu'un code moins compact. La rapidité d'un code se joue surtout sur
- éviter autant que possible x->y->z et préférer à la place stocker x->y dans tmp puis utiliser tmp->z
- éviter autant que possible tab[i] (surtout si on le répète plusieurs fois ou si "tab" stocke un tableau de structures) et préférer utiliser "<type*> tmp=tab" puis "*tmp" associé à "tmp++"
Et d'autres règles que je connais moins (comme l'ordre des membres d'une structure, l'alignement d'une structure sur des tailles bien précises quand on veut en avoir beaucoup dans un tableau etc...)
07/12/2007, 07h23
Melem

Citation:

Au débuts du C c'est ce que croyaient les programmeurs. A savoir que plus le code était compact et plus il était rapide.
Au fil du temps (et aussi avec l'optimisation des compilos), ils se sont rendus compte qu'un code compact n'était pas forcément plus rapide qu'un code moins compact.

Il n'était pas question de vitesse, il était question d'écriture. Comme je l'ai dit, notamment du fait de sa longueur, du code trop décompacté peut devenir illisble, donc il faut savoir faire un compromis. Le gain en vitesse peut avoir lieu, mais c'était un deuxième argument, que j'ai bien pris la peine de mettre entre parenthèses. Et pour terminer, vous ne voyez pas qu'on c'est déjà assez écarté du sujet comme ça?

Citation:

Envoyé par Melem

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.

Hé ben moi j'avais un peu de temps ce matin et j'ai compilé les deux codes suivants
Code 1
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 void str_cpy(char * dest, char * src) { while (*dest++ = *src++); } int main() { char source[0x10000 + 1]; char dest[0x10000 + 1]; unsigned long i; // Initialisation for (i=0; i < 0x10000; i++) source[i]='.'; source[i]=0; // Copie for (i=0; i < 10000; i++) str_cpy(dest, source); return 0; }
Code 2
Code:

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 char * str_cpy(char *dest, char const *src) { char *p_ret=0; while (*src != 0) { *dest = *src; dest++; src++; } p_ret = dest; return p_ret; } int main() { char source[0x10000 + 1]; char dest[0x10000 + 1]; unsigned long i; // Initialisation for (i=0; i < 0x10000; i++) source[i]='.'; source[i]=0; // Copie for (i=0; i < 10000; i++) str_cpy(dest, source); return 0; }
J'ai lancé plusieurs fois l'un ou l'autre en les chronométrant sur un Linux récent (en utilisant le "time <nom pgm>". Et je les lançais parfois l'un en premier, parfois l'autre. Je les ai même lancés les deux en parallèle dans deux fenêtres différentes (ils ne démarraient qu'à la création d'un fichier que je créais depuis une 3° fenêtre pour bien qu'ils partent en même temps). Ben c'est toujours le code n° 2 qui était le plus rapide. Bon j'ai pas non plus fait 300 essais donc ma démo n'est pas non plus parfaite mais ça donne quand-même à réfléchir...

Citation:

Envoyé par Melem

Et pour terminer, vous ne voyez pas qu'on c'est déjà assez écarté du sujet comme ça?

Ah ? T'apprécies pas le plaisir de la discussion ??? ;)

07/12/2007, 10h18
Melem

Citation:

Envoyé par Sve@r

c'est toujours le code n° 2 qui était le plus rapide.

T'es sur que t'as pas triché? :lol:. Je crois que moi aussi je devrais faire des tests, comme ça on pourra confronter nos résultats.
07/12/2007, 10h54
Melem

Ben voilà, t'as bien triché! :lol:. Ta fonction ne copie pas le caractère de fin de chaîne (même remrque pour la fonction de Thierry). On avait tellement l'esprit ailleurs que personne ne l'a remarqué mais bref ... après la boucle tu dois encore ajouter le '\0', que tu n'a pas copié, ce qui fait une opération de plus, à moins de changer la boucle en do ... while et de boucler tant que *(src - 1) != '\0' et qui n'est finalement pas si lisible que ça, la preuve tout le monde s'est trompé ... :yaisse2: :mouarf:
07/12/2007, 11h01
Thierry Chappuis

Citation:

Envoyé par Melem

Ben voilà, t'as bien triché! :lol:. Ta fonction ne copie pas le caractère de fin de chaîne (même remrque pour la fonction de Thierry). On avait tellement l'esprit ailleurs que personne ne l'a remarqué mais bref ... après la boucle tu dois encore ajouter le '\0', que tu n'a pas copié, ce qui fait une opération de plus, à moins de changer la boucle en do ... while et de boucler tant que *(src - 1) != '\0' et qui n'est finalement pas si lisible que ça, la preuve tout le monde s'est trompé ... :yaisse2: :mouarf:

Il n'a pas triché, c'est une grosse erreur de ma part. Au temps pour moi. J'ai corrigé mon code ici: http://www.developpez.net/forums/sho...6&postcount=16

Thierry
07/12/2007, 11h09
Melem

Citation:

Envoyé par Thierry Chappuis

Citation:

Envoyé par Melem

Ben voilà, t'as bien triché! . Ta fonction ne copie pas le caractère de fin de chaîne (même remrque pour la fonction de Thierry). On avait tellement l'esprit ailleurs que personne ne l'a remarqué mais bref ... après la boucle tu dois encore ajouter le '\0', que tu n'a pas copié, ce qui fait une opération de plus, à moins de changer la boucle en do ... while et de boucler tant que *(src - 1) != '\0' et qui n'est finalement pas si lisible que ça, la preuve tout le monde s'est trompé ...

Il n'a pas triché, c'est une grosse erreur de ma part. Au temps pour moi.

Mais bien sûûûû...ûr :D. Mais ca ne change rien à ma conclusion :).
07/12/2007, 11h24
Thierry Chappuis

Citation:

Envoyé par Melem

Mais bien sûûûû...ûr :D. Mais ca ne change rien à ma conclusion :).

Ca prouve juste que personne n'a relu ma fonction, y compris moi. J'admets que cette erreur grave ne parle pas en faveur de mon implantation.

Thierry
07/12/2007, 16h55
Sve@r

Citation:

Envoyé par Melem

Ben voilà, t'as bien triché! :lol:. Ta fonction ne copie pas le caractère de fin de chaîne (même remrque pour la fonction de Thierry). On avait tellement l'esprit ailleurs que personne ne l'a remarqué mais bref ... après la boucle tu dois encore ajouter le '\0', que tu n'a pas copié, ce qui fait une opération de plus, à moins de changer la boucle en do ... while et de boucler tant que *(src - 1) != '\0' et qui n'est finalement pas si lisible que ça, la preuve tout le monde s'est trompé ... :yaisse2: :mouarf:

Exact. Les tests ne sont pas bons :chin:
C'est vrai que ça m'étonnait aussi car je m'attendais à avoir tantôt l'un tantôt l'autre (en fonction de la charge machine, de l'ordre de lancement, etc...)...
08/12/2007, 10h47
Pierre Maurette
Je reviens un peu sur cette fameuse fonction à optimiser ou à ne pas optimiser.

- Si la fonction est déclarée et documentée dans son .h, en bref si elle n'est pas static pour les quelques (voire une seule) fonctions qui l'utilisent, il est normal de la sécuriser un minimum dans la tradition de C. A moins éventuellement d'en faire une unsafe_str_cpy(), par exemple.
A noter que la sécurisation en C ne peut pas aller bien loin. Pour ce genre de pointeur on peut juste vérifier qu'il n'est pas à NULL. Donc en gros considérer que le programmeur utilisateur sera assez "tête en l'air" pour ne se conformer à la documentation de la fonction, voire à l'évidence, et assez rigoureux (ou ses outils) pour être certain que tout pointeur non autrement initialisé ou libéré sera à NULL. On va donc très certainement avoir une foultitude de tests de pointeurs à NULL, redondants, mais si c'était un vrai problème, ça se saurait.
Un petit truc me chagrine quand même: le retour char*. On connaît l'utilité de renvoyer un paramètre pointeur non constant, dans l'écriture plus naturelle du code qu'elle autorise, dans strcat() par exemple. Mais ici, le fait de mettre le retour à NULL quand src OU dest est à NULL rend le machin difficile à utiliser. Ou alors quelque chose m'échappe. Peut-être pourrait-on envisager une enum
Code:

1 2 3 4 5 enum STR_CPY_RETURN { STR_CPY_SUCESS = 0, STR_CPY_DSTBAD = 1, STR_CPY_SRCBAD = 2 };
ou autre, dans laquelle on peut lire la cause de l'erreur par masquage.

- Pour ce qui est de l'optimisation, il faut avant tout qu'elle ait un sens. C'est à dire que les nanosecondes gagnées dans le test à NULL soient visibles dans le contexte.
Nota: à mon avis, du code "bêtement trop lent" est le plus souvent "bête" avant d'être "trop lent".
Ici le contexte pourrait être un ou des tableaux de char*, correctement initialisés à des tailles suffisantes. Ensuite, des centaines ou plus de copies de chaînes, parce qu'on a une bonne raison de swapper les chaînes et non les pointeurs. Plus les chaînes seront nombreuses et courtes, plus l'optimisation se fera sentir.
C'est là qu'on sera tenté par
Code:

1 2 3 4 void str_cpy(char * dest, char * src) { while (*dest++ = *src++); }
Mais ce sera déjà impérativement:
Code:

1 2 3 4 static void str_cpy(char * dest, char * src) { while (*dest++ = *src++); }
Mais à ce moment-là, l'appel de fonction, s'il n'est pas optimisé par le compilateur, deviendra plus coûteux qu'un test à NULL une fois dans la fonction. Autant le suggérer au compilateur, suggestion valant commentaire à la relecture du code:
Code:

1 2 3 4 static inline void str_cpy(char * dest, char * src) { while (*dest++ = *src++); }
Notez que pour faire taire un warning "mérité" et rendre votre code lisible, sans changer le code généré (quelques microsecondes de plus pour la compilation, vous devriez au moins faire:
Code:

1 2 3 4 static inline void _str_cpy(char* dest, const char* src) { while ((*dest++ = *src++) != '\0'); }
Mais maintenant, à quoi sert la fonction par rapport à une macro, ou tout simplement un copié-collé du while() ? D'autant qu'alors ce code apparaîtrait directement dans le bloc où les pointeurs auront déjà été validés.

Une voie d'optimisation serait, en fonction du contexte, de copier un nombre fixe de char, c'est à dire le plus souvent "un peu trop". Mais ça peut aller bien plus vite, dans certains cas, en particulier si ce nombre peut être connu avant la compilation. Et pourquoi pas multiple de sizeof(int).
08/12/2007, 12h48
PsychoH13

Je tiens à vous rappeler que selon le standard la fonction strcpy() retourne l'adresse du premier caractère de la chaîne de destination, et cette particularité est absente de toutes vos optimisations.
08/12/2007, 13h22
Sve@r
Citation:
Envoyé par Pierre Maurette

Je reviens un peu sur cette fameuse fonction à optimiser ou à ne pas optimiser.

- Si la fonction est déclarée et documentée dans son .h, en bref si elle n'est pas static pour les quelques (voire une seule) fonctions qui l'utilisent, il est normal de la sécuriser un minimum dans la tradition de C. A moins éventuellement d'en faire une unsafe_str_cpy(), par exemple.
A noter que la sécurisation en C ne peut pas aller bien loin. Pour ce genre de pointeur on peut juste vérifier qu'il n'est pas à NULL. Donc en gros considérer que le programmeur utilisateur sera assez "tête en l'air" pour ne se conformer à la documentation de la fonction, voire à l'évidence, et assez rigoureux (ou ses outils) pour être certain que tout pointeur non autrement initialisé ou libéré sera à NULL. On va donc très certainement avoir une foultitude de tests de pointeurs à NULL, redondants, mais si c'était un vrai problème, ça se saurait.
Un petit truc me chagrine quand même: le retour char*. On connaît l'utilité de renvoyer un paramètre pointeur non constant, dans l'écriture plus naturelle du code qu'elle autorise, dans strcat() par exemple. Mais ici, le fait de mettre le retour à NULL quand src OU dest est à NULL rend le machin difficile à utiliser. Ou alors quelque chose m'échappe. Peut-être pourrait-on envisager une enum

Code:

1 2 3 4 5 enum STR_CPY_RETURN { STR_CPY_SUCESS = 0, STR_CPY_DSTBAD = 1, STR_CPY_SRCBAD = 2 };

ou autre, dans laquelle on peut lire la cause de l'erreur par masquage.

- Pour ce qui est de l'optimisation, il faut avant tout qu'elle ait un sens. C'est à dire que les nanosecondes gagnées dans le test à NULL soient visibles dans le contexte.
Nota: à mon avis, du code "bêtement trop lent" est le plus souvent "bête" avant d'être "trop lent".
Ici le contexte pourrait être un ou des tableaux de char*, correctement initialisés à des tailles suffisantes. Ensuite, des centaines ou plus de copies de chaînes, parce qu'on a une bonne raison de swapper les chaînes et non les pointeurs. Plus les chaînes seront nombreuses et courtes, plus l'optimisation se fera sentir.
C'est là qu'on sera tenté par

Code:

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

Mais ce sera déjà impérativement:

Code:

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

Mais à ce moment-là, l'appel de fonction, s'il n'est pas optimisé par le compilateur, deviendra plus coûteux qu'un test à NULL une fois dans la fonction. Autant le suggérer au compilateur, suggestion valant commentaire à la relecture du code:

Code:

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

Notez que pour faire taire un warning "mérité" et rendre votre code lisible, sans changer le code généré (quelques microsecondes de plus pour la compilation, vous devriez au moins faire:

Code:

1 2 3 4 static inline void _str_cpy(char* dest, const char* src) { while ((*dest++ = *src++) != '\0'); }

Mais maintenant, à quoi sert la fonction par rapport à une macro, ou tout simplement un copié-collé du while() ? D'autant qu'alors ce code apparaîtrait directement dans le bloc où les pointeurs auront déjà été validés.

Une voie d'optimisation serait, en fonction du contexte, de copier un nombre fixe de char, c'est à dire le plus souvent "un peu trop". Mais ça peut aller bien plus vite, dans certains cas, en particulier si ce nombre peut être connu avant la compilation. Et pourquoi pas multiple de sizeof(int).
Plein d'éléments intéressants dans cette discussion. Je comprends pas trop pourquoi mettre la fonction en "static" (si on est dans un projet multisources ça va moins bien marcher) mais j'aime bien l'ensemble.

Bon, je peux apporter quelques réponses
1) pourquoi dédier la copie (une ligne) à une fonction plutôt que recopier la ligne dans le code => évolutivité. Aujourd'hui les strings C ont une caractéristique mais demain cela peut en être une autre. Une fonction = une modif. Alors que si on a copié la ligne dans le code...
2) les remarques sur le contrôle inhérent avant d'entamer la copie sont excellentes. Rappelons que quand le C a été inventé, sa philosophie était "le programmeur sait ce qu'il fait". Si le programmeur passe un pointeur invalide à str_cpy() ben je vais pas pleurer sur son sort.

Citation:

Envoyé par PsychoH13

Je tiens à vous rappeler que selon le standard la fonction strcpy() retourne l'adresse du premier caractère de la chaîne de destination, et cette particularité est absente de toutes vos optimisations.

Exact. Mais il s'agit d'une discussion plus dans un ton "général" à but lucratif qu'un projet à développer donc on peut passer ce détail qui n'enlève rien aux développements exposés...

En revanche, ce qui m'inquiète, c'est que j'ai appris récemment que la simple présence d'une adresse invalide dans une variable de type "pointeur" invoquait un comportement indéterminé => http://www.developpez.net/forums/sho...=436475&page=2.
Cela signifie que la boucle " while (*dest++ = *src++);" apporte un comportement indéterminé vu qu'en fin de boucle, "dest" et "src" ont dépassé l'espace de leur définition. J'aimerais bien qu'Emmanuel vienne jeter un oeuil sur ce débat et y apporter sa contrib car si mes conclusions sont correctes, cette fonction ne convient plus...

Citation:

Envoyé par Sve@r

Je comprends pas trop pourquoi mettre la fonction en "static" (si on est dans un projet multisources ça va moins bien marcher)

Au contraire, non ?
"static" ici ça signifie que la fonction ne sera visible que dans le module(*). En gros, j'ai choisi (erreur de ma part ?) que:

- soit une fonction est utilisable hors du module, et je vais la déclarer et la documenter vers l'utilisateur dans le .h et la définir (et la documenter vers le programmeur) dans le .c.

- soit elle est à pour la cuisine interne du module, elle n'a pas à être utilisée par d'autres modules, pire elle ne doit pas entrer en conflit avec une fonction de même nom définie à un endroit ou à un autre du projet, #include-s compris. Alors elle sera déclarée et définie en même temps dans le .c, avec "static" (rien ou "extern", c'est pareil). On peut dans ce cas séparer définition et déclaration pour des raisons de référence "forward", mais c'est marginal.

Un exemple, qui montre aussi qu'on peut faire une fonction en "static inline" et y accéder de l'extérieur en même temps. Je pense qu'il y a dans mon code des précautions redondantes.
main.c
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <stdio.h> #include <stdlib.h> #include "pathkivabien\foo.h" static void debil(void) { puts("debil de main()"); } int main(void) { debil(); teste("Pierre"); grosseFonction(); grosMorceaudeGrosseFonction(); /* pour test ? */ return (0); }
foo.h
Code:

1 2 3 4 5 6 7 8 #ifndef FOO_H_ #define FOO_H_ void teste(const char* chaine); void grosseFonction(void); void grosMorceaudeGrosseFonction(void); #endif /*FOO_H_*/
foo.c
Code:

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 #include <stdio.h> #include "pathkivabien\foo.h" static void debil(void); static inline void inline_grosMorceaudeGrosseFonction(void); void grosMorceaudeGrosseFonction(void) { /* tuyauterie selon besoin*/ inline_grosMorceaudeGrosseFonction(); } void grosseFonction() { /* du code */ inline_grosMorceaudeGrosseFonction(); /* du code */ } void teste(const char* chaine) { debil(); puts(chaine); } static inline void inline_grosMorceaudeGrosseFonction(void) { puts("inline_grosMorceaudeGrosseFonction"); } static void debil(void) { puts("debil de foo()"); }
(*)j'utilise module, on peut lire "unité de compilation".

08/12/2007, 15h46
diogene

Citation:

Envoyé par Sve@r

En revanche, ce qui m'inquiète, c'est que j'ai appris récemment que la simple présence d'une adresse invalide dans une variable de type "pointeur" invoquait un comportement indéterminé => http://www.developpez.net/forums/sho...=436475&page=2.
Cela signifie que la boucle " while (*dest++ = *src++);" apporte un comportement indéterminé vu qu'en fin de boucle, "dest" et "src" ont dépassé l'espace de leur définition.

La norme garantit que l'adresse qui suit la fin d'un objet est une adresse légale.

n1124 :

Citation:

6.5.6 Additive operators
8....
Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.
9....
Moreover, if the expression P points either to an element of an array object or one past the last element of an array object, and the expression Q points to the last element of the same array object, the expression ((Q)+1)-(P) has the same value as ((Q)-(P))+1 and as -((P)-((Q)+1)), and has the value zero if the expression P points one past the last element of the array object, even though the expression (Q)+1 does not point to an element of the array object.89)

89)....
an implementation need only provide one extra byte (which may overlap another object in the program) just after the end of the object in order to satisfy the ‘‘one past the last element’’ requirements.
08/12/2007, 16h05
Emmanuel Delahaye

Citation:

Envoyé par diogene

La norme garantit que l'adresse qui suit la fin d'un objet est une adresse légale.

Oui, et je l'avais d'ailleurs rappelé dans mon article :

http://www.developpez.net/forums/sho...3&postcount=16