le compilateur optimise-t-il?

Bonjour.

J'ai souvent entendu que les compilateurs actuels etaient capable d'optimiser bien mieux que nous et qu'il fallait leur laisser cette tâche. Cela m'amène a la question suivante

dans une fonction "principale", j'appelle a la suite une série de fonction. Elles retournent toutes un booléen qui vaut true si l'execution a reussi, false sinon.
Dès qu'une des fonction retourne false, j'arrète l'execution de la fonction principale et je retourne false.

J'ai plusieures façon d'écrire ça:

1:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

bool fonction_principale() { bool valeurRetour=true;   valeurRetour = fonction1(); if(valeurRetour == true) { valeurRetour = fonction2(); if(valeurRetour == true) { valeurRetour = fonction3(); if(valeurRetour == true) { /* etc etc*/ } } } } return valeurRetour }

---

2:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

bool fonction_principale() { bool valeurRetour=true;   valeurRetour=fonction1(); if(valeurRetour=false) return false;   if(valeurRetour=true) valeurRetour=fonction2(); if(valeurRetour=false) return false;   if(valeurRetour=true) valeurRetour=fonction3(); if(valeurRetour=false) return false;   /* etc etc*/     if(valeurRetour=true) valeurRetour=fonctionN();   return valeurRetour; }

---

je trouve la deuxième méthode beaucoup plus lisible. Mais le problème c'est que si la fonction1 retourne false, il y aura encore (n-1) tests effectués pour rien. Ma question c'est : est-ce que le compilateur se rend compte que j'effectue plein de fois le meme test a la suite, et est-ce qu'il générera le même code machine que dans le premiers cas?
(ou est-ce qu'il ne faut pas trop pousser quand même^^)

Tu peux aussi faire ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

if( function1() && function2() && ... && functionN() ) { return true; } else { return false; }

---

Il testera tes fonctions dans l'ordre de l'appel dans ta condition if :)

Sinon, pour répondre à ta question première, l'optimisation du compilateur dépend de beaucoup de choses :

1) du compilateur : chaque compilateur a sa propre méthode d'optimisation
2) de la version du compilateur en question
3) de la demande explicite lors de la compilation, par exemple pour gcc tu peux préciser des paramètres commes "-O2" ou même "-O3" qui forcent certaines optimisations

Je pense qu'en règle générale, la compilation du compilateur est "suffisament" optimisée. Il incombe au programmeur d'avoir un code performant, et il ne faut pas trop compter sur les options d'optimisations pour pallier à une faute de design qui entrainerait un gouffre de performances.

Merci bien pour ta réponse, elle me convient parfaitement.

Pour l'exemple que tu m'as donné avec les AND, tu veux dire que dès qu'une des fonctions retourne false. il retourne false sans appeler les fonctions suivantes?

Si c'est le cas c'est vraiment bon à savoir.

Oui c'est exactement ce qu'il va faire : ça permet par exemple dans un même if de tester l'existence d'un fichier avant de tester sa longueur; sans provoquer une erreur de lecture lors du test de la longueur si le fichier n'existe pas.

Une règle d'optimisation est d'ailleurs de placer en tête les conditions les plus probables dans un if qui contient plusieurs conditions, ainsi on a plus de chance de sortir "plus vite" de la condition.

Ok, je pense m'en servir souvent.
MERCI

Si tes retours à false correspondent à des erreurs, alors tu peux te tourner vers les exceptions. Du coup ton code sera beaucoup plus simple, et plus efficace.

A part ça, effectivement ton code est une version beaucoup plus compliquée (mais équivalente) de ça :

Code:

---

1 2 3 4

bool fonction_principale() { return fonction1() && fonction2() && ... && fonctionX(); }

---

Pour en rajouter une louche, on ne teste jamais si une variable booléenne est vrai ou fausse.
Par définition un booléen est vrai ou faut, tester sa valeur via une comparaison avec '=='
est inutile et redondant.
En d'autres termes on n'écrit pas :

Code:

---

if (monBool == true) { ... }

---

Mais :

Code:

---

if (monBool) { ... }

---

Il y a aussi ces 2 methodes:

Code:

---

1 2 3 4 5 6 7 8 9 10

bool fonction_principale() { if(fonction1()) if(fonction2()) if(fonction3()) /* etc etc*/ return fonctionN(); return false; }

---

ou son pendant mais que je trouve moins elegant mais qui permet de ne pas partir trop loin en indentation

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

bool fonction_principale() { if(!fonction1()) return false; if(!fonction2()) return false; if(!fonction3()) return false; /* etc etc*/ return fonctionN(); }

---

Une autre chose qu'il m'est arrivé de faire, c'est:

Code:

---

1 2 3 4

bool bOK=true; bOK = bOK && fonction1(); bOK = bOK && fonction2(); bOK = bOK && fonction3();

---

C'est quoi ce désir de ce compliquer la vie ?

La solution donnée par Loulou est simple (en supposons que l'on parle couramment le booléen de la rue (ce n'est pas comme si il s'agissait d'une table de carnot (ortho?) réduite) ; si ce n'est pas le cas, il est temps de s'y mettre) et efficace.

A la limite la solution donnée par médinoc (avec &&=) pour si on veut débugguer. Mais bon.

Il faut penser à la maintenance : tout mettre dans le return, ça pose un problème, pour le jour où il faut faire autre chose qu'un return :wink: Avec un if, on est libre de faire ce qu'on veut, un return, un appel de méthode, ou autre !

( pour défendre un peu ma cause :P )

Karnaugh :)

Citation:

---

Envoyé par Miles

Karnaugh :)

---

Arf que c'est vieux.

Pour les exécutions supplémentaires ... ben si il devait vraiment y avoir des trucs à faire, avec toutes les possibilités (8 ici), il y aura pas mal de changements dans le code. Autant faire simple en attendant.
(et puis avec un bon éditeur de code customisé, et en quelques appuis de touches, le test est déplacé et réindenté dans la condition d'un "if" 8))