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.