Discussion :

[tlemcenvisit]

Salut
Je cherche à savoir lequel de ces deux codes est le plus performant :

Code :

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

1
2
3
4
5
6
7
8
void function(int i)
{
 if(i==0){
 cout<<"impossible";
 return;
 }
 //suite de la fonction
}

et

Code :

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

1
2
3
4
5
6
7
8
9
10
void function(int i)
{
 if(i==0){
 cout<<"impossible";
 }
else
 {
 //suite de la fonction
 }
}

Merci de bien vouloir m'aider

[capitN.flam]

Salut
Je cherche à savoir lequel de ces deux codes est le plus performant :

Code :

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

1
2
3
4
5
6
7
8
void function(int i)
{
 if(i==0){
 cout<<"impossible";
 return;
 }
 //suite de la fonction
}

et

Code :

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

1
2
3
4
5
6
7
8
9
10
void function(int i)
{
 if(i==0){
 cout<<"impossible";
 }
else
 {
 //suite de la fonction
 }
}

Merci de bien vouloir m'aider

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.

[Caine]

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.

[Kaktus]

Bonjour,


A ta place, je partirai du cas le plus fréquent, c'est à dire quand i n'est pas nul.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
void function(int i) {
 
       if (i!=0) {
            /* Ton code */  ; }
       else      { 
            cout <<" impossible" << endl; };
}
 
Cela évite un débranchement dans la plupart des cas.

[JolyLoic]

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 :

Code :

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

1
2
3
4
5
6
7
8
9
void function(int i)
{
  if(i==0){
  cout<<"impossible";
  }
  else {
     faitLeBoulot();
  }
}

En terme de performances :
- 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.

[Caine]

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

[Aurelien.Regat-Barrel]

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

[mavina]

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

[tlemcenvisit]

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

[Caine]

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.

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

[Kaktus]

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 :

Code :

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

1
2
 
if (i !=0) function(i);

dans le corps de ton programme appelant.
( Dans ton cas, si i est nul on n'exécute pas void function(int i).)

[tlemcenvisit]

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?

[Aurelien.Regat-Barrel]

A mon avis, au niveau performance, ça ne change strictement rien, le compilateur optimisant les 2 pareil.

[Luc Hermitte]

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

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

[Caine]

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.

[tlemcenvisit]

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

[Caine]

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

[tut]

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

[Caine]

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

[JolyLoic]

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

Code :

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

1
2
3
4
5
6
7
8
9
10
map <string, int> frequences(istream &f)
{
  string mot;
  map<string, int> freq;
  while (f >> mot)
  {
    freq[mot]++;
  }
  return freq;
}

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.