Version imprimable
Salut
Je cherche à savoir lequel de ces deux codes est le plus performant :etCode:
2
3
4
5
6
7
8
Merci de bien vouloir m'aiderCode:
2
3
4
5
6
7
8
9
10
Personellement je trouve la deuxieme solution beaucoup plus propre. Et, mais je peux me tromper, je ne pense pas qu'il y ait une difference de performance.Citation:
Envoyé par tlemcenvisit
Bonjour,
D'un point de vue lisibilité les deux codes se valent.
Dans le premier cependant, il y a un branchement vers return en cas de nullité de i.
Deuxième code:
Il y a evaluation d'une condition puis saut court si la condition est fausse vers le code de la clause else. A la fin de la clause else, il y a un nouveau saut court vers la suite du code ou la sortie de la fonction.
Premier code:
Il y a toujours évaluation de la condition, saut court vers la suite ou fion de fonction.
Donc, le premier code prend moins de cycle processeur pour s'éxecuter. De plus, pour être complet, il est plus compact que le deuxième code, le code C++ traduit en upcode (code généré en binaire) est moins volumineux et se charge plus rapidement dans le pipeline du processeur.
Attention tout de même, ces considérations sont de l'ordre de la dizaine de nanosecondes, pas plus.
Bonjour,
A ta place, je partirai du cas le plus fréquent, c'est à dire quand i n'est pas nul.
Code:
2
3
4
5
6
7
8
9
10
Dans le cas où il y a un seul test, les deux codes me semblent assez lisibles.
Dans le cas où il y en a plusieurs, le deuxième peut devenir préférable.
Si le deuxième commence à devenir préférable, un troisième pointe le bout de son nez :
En terme de performances :Code:
2
3
4
5
6
7
8
9
- Est-ce que ton profiler t'as montré qu'il y avait un goulot d'étranglement dans ta fonction ?
- Si oui, il doit te permettre de mesurer les alternatives et de choisir la plus rapide
- Si non, à quoi ça sert de micro-optimiser ?
- De toute façon, je serais très surpris qu'il y ait la moindre différence dans ces cas.
Il faut demander au compilateur de traduire les deux codes en assembleur pour voir la différence, qui se joue à un jump de plus dans le deuxième cas.
D'un autre côté, c'est vrai que suivant l'agencement des modules, le ret du return peut être plus long que le jump du deuxième cas.
Pour les problèmes de performances, l'assembleur est ton ami, on ne peut pas toujours profiler du code (Embarqué notamment).
Je me pose aussi la question de mettre ou non le else. Ne pas le mettre économise un bloc d'accoaldes, donc un retrait supplémentaire du code. Mais les puristes considèrent que le flot d'exécution doit toujours se terminer à la fin du code de la fonction et qu'un return en cours de route est un sacrilège...
moi on m'a appris a faire la deuxième solution, le return arrettant net si la condition est respectée, il ne cherchera pas à aller à la fin du else pour vérifier si il reste du code à executer, un tout petit(tout petit tout petit) gain de temps
En général, les programmeurs utilisent la deuxième méthode, je voulais savoir les inconvénients de la 1ere
C'est surtout ça l'objectif de la question
Alors tu as mal formuler ta question, car les inconvénients de la première méthode concerne d'autres domaines que la vitesse du code.
En preuve de programme, en analyse avant-arrière aussi,il peut devenir difficile de prédire les valeurs de sortie d'un fonction truffée de (if return) même en fixant les valeurs des arguments, surtout quand les tests font appels à des variables globales calculées dans d'autre modules.
De plus, dans certaines normes de programmation comme SSIL 4, il est interdit d'utiliser cette forme de programmation.
Citation:
Envoyé par tlemcenvisit
En algorithmique, on se débrouille toujours pour mettre le cas général (comprendre le cas où tout marche sans erreur) en place prioritaire, d'où ma proposition de traiter le cas (i!=0).
Tu peux même écrire :
dans le corps de ton programme appelant.Code:
2
( Dans ton cas, si i est nul on n'exécute pas void function(int i).)
Les normes de programmation !
C'est un concept que je ne connais pas
Et qu'est ce qu'il y a comme normes de programmation aussi?
A mon avis, au niveau performance, ça ne change strictement rien, le compilateur optimisant les 2 pareil.
Les puristes initiés savent qu'il est illusoire d'avoir un programme aisé à maintenir avec un flot d'exécution qui va gentillement attendre le return. Surtout en C++, grâce aux exceptions, on a plein de déroutements potentiels qui surgissent.Citation:
Envoyé par Aurelien.Regat-Barrel
Forcer le SESE au mileu d'exception est je trouve un défi pour les amateurs de code spaghetti.
La règle du SESE (single entry single exit) a deux intérêts en ce qui me concerne :
- quand une fonction est tellement longue qu'elle en devient trop difficile à maintenir/comprendre sans SESE
- quand on a des ressources gérées à la main.
Dans les règles que je considère vraiment importantes, il y a :
- fonctions simples, (très) courtes et limitées à une tâche simple (rejoint le principe des raffinements successifs)
Ensuite, moins connu et pourtant hyper utilie :
- Gestion déterministe des ressources (via RAII)
Autant dire que le SESE ne sert plus à rien sauf à me faire me poser des questions pour savoir où intervient le booleen qui autorise à continuer la boucle.
Une fonction find de 4 lignes (5 avec la signature) avec un return en plein milieu de la boucle de recherche est suffisament idiomatique pour ne pas avoir à s'encombrer du SESE.
Une fonction de 40 lignes qui fait son find à elle, puis une notification (en bouclant sur tous les élements liés à celui trouvé), et enfin un retrait de l'élément trouvé (boucle explicite de nouveau), c'est n'importe quoi.
Le SESE est utile dans certains domaines, comme les automates embarqués et sécurisés. Ou il peut tout simplement s'agir de règles de codage d'une SSII.
Cependant, il est vrai, je ne comprends toutjours pas en quoi coder en SESE ou non est plus sécurisé. En tant que programmeur averti, je ne vois pas le problème.
Par contre dans l'analyse Avant/Arrière qui sert parfois pour determiner les valeurs de test de modules, une fonction non SESE devient vite pénible à analyser.
Chaque domaine informatique a ses règles et besoins de programmation.
Comme je l'ai indiqué, la problématique de la performance comme des incovénients des deux types de codes est surtout de l'ordre de l'information.
Effectivement quelque soit le choix du programmeur, s'il enclenche les optimisations du compilateur, celui-ci tranformera le code pour obtenir le meilleur code assembleur possible et le plus performant.
Je n'ai pas de concepts si avancés en programmation
Merci de bien vouloir me dire ce que je dois utiliser de préférence, avec une simple explication si c'est possible
Tu sais les concepts avancés viennent en se documentant :)
La conclusion est que tu peux utiliser les deux formes. Tu as le choix, à ce niveau l'une ou l'aure est plus une question de style voir de préférence.
Perso, je préfère plusieurs return au lieu de trop d'imbrication de if ... else if ...
"un seul return par fonction"
est une des règle de codage que j'ai toujours vu dans tous les projets auxquels j'ai participé.
Ca permet une meilleure lisibilité du code. Au début j'étais sceptique, mais c'est vrai que quand tu as du code à lire/comprendre/débugger et que ce n'est pas le tien, ce genre de règle prend toute leur importance. C'est tout simplement plus lisible, plus facile à comprendre, le gain de performance, s'il y en a, étant dans la plupart des cas négligeable. Je précise bien dans la plupart des cas, pour ne pas me faire incendier par les gourous.
D'un point de vue Génie Logiciel, cette règle n'est pas idiote, elle vas dans le sens de l'uniformisation du code source, ce qui procure une meilleure maintenabilité.
Oui et non, je lis régulièrement du code qui enfreind la règle SESE sans que ça ne me pose le moindre souci de compréhension (non pas que le code soit bien écris, loin de là).
C'est comme tout, chacun a son domaine de prédilection. C'est surtout en preuve de programme que ça devient critique à mon avis (puisque le topic est un sodage maintenant ).
Avant de discuter des bienfaits du SESE, j'aimerais que l'on me réécrive le bout de code suivant de telle manière qu'il soit SESE. On pourra alors comparer la lisibilité sur un exemple concrêt (attention, cet exemple est subversif :bug: ) :
Là où je suis d'accord, c'est qu'il faut éviter qu'une fonction contienne des structures de contrôle trop complexes, afin d'éviter le code spaguetti. Mais ça n'a rien à voir avec SESE.Code:
2
3
4
5
6
7
8
9
10
a- N'est-on pas dans un cas de C++ sans exceptions (C++ embedded ou avec options de compilations qui vont bien, voire en C simplement) ?Citation:
Envoyé par Caine
b- Dans un environnement pur "itératif" (sans déroutements implicites, je veux dire), c'est (était) un bon moyen d'obtenir une libération déterministe de ressources (si on ne dispose d'aucun objet automatiquement libéré en fin de portée)
Sinon, c'est plus stylistique qu'autre chose.
c- Certes, mais une simple fonction C++ (c'est important. Nous sommes ici en C++) qui fait un simple new (implicitement ou explicitement) est par défaut non SESE. Ces traitements de preuves automatiques vont alors avoir bien des difficultés. Si ils résistent aux new, ils devraient être capables de mieux résister au non SESE.
d- Perso, cela me ralenti plus qu'autre chose. Cela me fait chercher où ça commence, où c'est modifié et où c'est exploité (hors condition de bouclage, c'est rarement le cas sauf le jour où c'est exploité...).Citation:
Envoyé par tut
Mais il est vrai que c'est plus le fait d'une fonction trop longue, que d'un SESE.
e- D'un point de vue C++, c'est ignorer le fait que les exceptions changent la donne, et qu'elles ne sont pas toujours explicites.
Et comme je le disais, je trouve que la règle : "fonction simple" est 100 fois plus importante. Hors ressources gérées à la C, c'est le seul truc qui pourrait me faire considérer le SESE.
Or je privilégie (dans la mesure du possible) la fonction simple, fonction dans laquelle le SESE n'a plus aucune impact sur l'aide à la compréhension.
f- Oui et non. Si le code est simple, le SESE n'aide en rien à mieux comprendre la fonction. Or c'est un argument fer de lance des règles de qualité pro-SESE, j'ai bien l'impression. (Plus que la gestion des ressources).Citation:
Envoyé par Loïc
Les personnes qui n'y ont pas réfléchi et à qui j'en parle, vont plus souvent me parler de compréhension (ou maintenabilité, c'est un combat proche) de la fonction que gestion des ressources.
On m'a toujours appris que dans une fonction, on élimine d'abord les cas simples, puis on traite les cas complexes.
Le cas if(i==0), est un cas simple, on sort (return), pas la peine de traîner dans la fonction.
Côté performance, j'en sais rien...
Quand j'écris une nouvelle fonction, je pense à éliminer les cas simples très rapidement. Ca me permet de programmer un peu plus rapidement parce que j'ai moins de problème lors du débugage et que je peux me concentrer plus sur l'algorithme.
Mais je dois surement utiliser les deux formes des fois. Je ne pense pas que ce soit une question existencielle de programmeur.
Ce qui me gêne dans le SESE, c'est l'augmentation des niveaux d'ombrication dû aux blocs else supplémentaires. La règle que j'applique personnelement c'est pas plus de 3 blocs imbriqués. C'est facile de les atteindre avec le SESE.
J'ai découvert ce concept de SESE en posant une question sur le pourquoi du code suivant, si cette tournure surprenante était justifiée:
au lieu de quelque chose de plus "classique" :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Le 1° code m'avait pas mal dérouté...Code:
2
3
4
5
6
7
8
9
10
11
Pareil que le monsieur, perso je suis en ce moment sur uen appi de telephone portable, le plus gros pb est le manque de memoire alors il faut tester tous les resultats d'affectation si je prends un traitement d'imageCitation:
Envoyé par Aurelien.Regat-Barrel
Il faut allouer dela place et a chaque nouvvelle étape verifier que l'on à la mem sachant qu'il y a au moins une diziane de passage critiques je me vois mal mettre des
sur trois kilometresCode:
2
3
Perso tant que c'est pas trop lourd SESE me parait le plus "jolie" masi aprs un certain nombre de if else au diable return en plein mileiu et hop
En fait, je préfère utiliser un système "défensif" dans mon code : tester les préconditions (avec return systématique en cas de défaut), avec rollback des initialisations partielles précédentes si nécessaire.
A partir d'un certain stade, je suis en "terrain connu", et appliquer un SESE sur cette portion de fonction est envisageable... Mais la fonction elle-même n'est plus SESE de toutes façons !!
En plus, j'avoue que je n'ai jamais compris comment le principe SESE pouvait être compatible avec les exceptions... Or, c'est bien un forum C++, ici, non ? :mrgreen:
J'avoue que je n'ai pas spécialement de problèmes avec les return multiples dans un code, dans le pire des cas je pose des breakpoints ou des traceurs dessus et basta ! On retrouve vite "le" return coupable...
De toutes façons, si l'on fait les choses proprement (= code d'erreur en retour de fonction, utilisation de SetLastError sur Win32, etc...), on sait systématiquement quel est le return ayant provoqué le retour... Si ce n'est pas le cas, y'a un développeur qui a codé comme un sagouin, et ça n'a rien à voir avec le fait que la fonction soit SESE ou pas.
Perso, je trouve que "if(condition)return;..." est beaucoup plus lisible, car, dans des programmes avec des dizaines de classes, structures, tests, fonctions... c'est à dire des dizaines d'accolades à la suite, on s'y perd un peu