Discussion :

[trecks]

Bonjour à tous.
Que signifie un "Return;" dans une ligne de code sans aucun paramètres derrière?

[Bakura]

Ca veut dire que tu sors de la fonction, tu rends la main à la fonction appelante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void UneFonction (int variable)
{
   if (variable == 0)
      return; // On rend la main à la fonction appelante
   else
      std::cout << variable;
}
 
int main()
{
   UneFonction (0)
   return 0;
}

[trecks]

Super merci beaucoup ça devrait bien m'aider
Merci encore
++

[koala01]

Salut,

Cependant, il faut noter que c'est plutôt comme solution ...

Je manque de temps dans l'immédiat pour motiver ma réponse, mais, promis, je la poste en rentrant, ne te vexe donc pas *trop*

[befalimpertinent]

En gros cela permet de sortir d'une fonction renvoyant void avant le return automatique de la fin de la fonction.

Très pratique parfois pour se sortir d'un cas spécial mais utiliser à outrance ça tourne un peu à la programmation spaghetti. (Sans compter la maintenance, le debuggage, ...)

Aussi pour un code simple il faudrait plutôt privilégier :

Code :

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

1
2
3
4
5
6
 
void UneFonction (int variable)
{
   if (variable != 0)
      std::cout << variable;
}

à

Code :

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

1
2
3
4
5
6
7
void UneFonction (int variable)
{
   if (variable == 0)
      return; // On rend la main à la fonction appelante
   else
      std::cout << variable;
}

[trecks]

Mais dans mon cas je n'ai pas trop le choix

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
void CSpriteManager::RegisterSprite(CSprite *pSprite)
{
    if(pSprite)
    {
        if(m_vSprite.size() > 0)
        {
			//Compare le ZOrder du sprite passé en paramètre avec le ZOrder chaque sprite du conteneur pour insérer le 
			//nouveau sprite avant un sprite du conteneur possédant un ZOrder plus grand que le sien
            for(m_SpriteIter = m_vSprite.begin(); m_SpriteIter != m_vSprite.end(); ++m_SpriteIter)
            {
                if(pSprite->GetZOrder() < (*m_SpriteIter)->GetZOrder())
		{
                    m_vSprite.insert(m_SpriteIter, pSprite);
		    return;
		}
            }
        }
	m_vSprite.push_back(pSprite);
    }
}

[koala01]

Enfin rentré...

En fait, il y a quatre points de vues qui plaident en défaveur de l'utilisation de return;, et chaque point de vue pourrait presque se suffire à lui-même:

1. Du point de vue sémantique:
   Quelqu'un qui dit que le rôle de return est de rendre la main à la fonction appelante n'a, c'est clair, pas tout à fait tord, mais il passe allègrement au delà d'une autre particulier de l'instruction return: celle de demander de renvoyer la valeur qui suit le mot clé à la fonction appelante.
   
   Il n'y a aucun sens à demander de renvoyer une valeur à une fonction... qui n'est pas prévue comme devant renvoyer une valeur
   
   Cela n'en a d'ailleurs pas plus de demander de renvoyer "la valeur qui suit le mot clé" alors... qu'il n'y a aucune valeur qui suit
   
2. Le point de vue de la programmation structurée nous indique en outre qu'il n'y a aucune raison de rompre brutalement l'ordre logique d'exécution sur base du résultat d'un test... A moins, bien sûr, que le test ne mette en évidence le fait que toute la gestion attendu de la part de la fonction a belle et bien été effectuée...
   
   Dans ce cas, la fonction doit simplement être quittée, ce qui devrait se traduire par l'absence d'instructions suivante
   
3. Le point de vue de l'algorithmie nous fait en outre remarquer que, si on en arrive à un algortihme tel que le code prend l'apparence de
   

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   void fonct()
   {
       //des trucs
       if'(test)
       {
           brol;
       }
       else
       {
           //le seul but est d'éviter l'exécution de bidule
           return;
       }
       bidule;
    
   }

   c'est que l'algorithme n'a "simplement" pas pris en compte le fait que "bidule" pourrait très bien se trouver dans la partie "vraie" du test, sans que cela ne nuise à la fonction... bien au contraire.
   
4. Enfin, le point de vue que j'appellerais "de la logique fainéante" nous fera remarquer que:
   • le bloc "Sinon" d'un test est facultatif
   • si on inverse le test, on peut faire passer les instructions se trouvant dans le bloc "Si" vers le bloc "Sinon" et inversément
   • si le bloc "Si" est vide et qu'on inverse le test, ce sera alors le bloc "Sinon" qui sera vide, et qui, devenant dés lors facultatif, n'a plus besoin d'être écrit, ce qui nous évite quelques lignes