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

[befalimpertinent]

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

On a toujours le choix
Mais dans ton cas précis ça ne me choque pas particulièrement.
Les autres solutions possibles seraient, par exemple :

1. utiliser le mot clé break pour sortir des boucles for (mais bon est ce vraiment mieux qu'un return --> pas si sur )
2. utiliser des boucles while qui test le critère d'arrêt (peut être la version la plus "propre" mais nombreux tests supplémentaires)

[trecks]

ok merci à tous pour vos réponses, je viens encore d'apprendre quelque chose, il est vraiment bien ce forum

[koala01]

En plus, tu peux parfaitement t'en passer, simplement décidant que le "push_back" se fasse dans la partie "else" du test

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
22
23
24
25
26
27
 
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);
		}
            }
        }
        else
        {
            m_vSprite.push_back(pSprite);
        }
    }
}

[koala01]

Et, d'ailleurs, pour gagner quelques itérations - car il est inutile de continuer à parcourir les éléments du tableau une fois que tu a inséré ton élément - tu aurais intérêt à remplacer ta boucle pour par une boucle while du genre 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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
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
             */
            m_SpriteIter= m_vSprite.begin();
            bool inserted=false; 
            while(m_SpriteIter!= m_vSprite.end() && inserted==false)
            {
                if(pSprite->GetZOrder() < (*m_SpriteIter)->GetZOrder())
                {
                    m_vSprite.insert(m_SpriteIter, pSprite);
                    inserted=true;
		}
                mSpriteIter++;
            }
        }
        else
        {
            m_vSprite.push_back(pSprite);
        }
    }
}

[Jean-Marc.Bourguet]

Koala, le comportement des deux fonctions est different. Et ta version me semble moins sensee...

[koala01]

J'étais un peut pressé lors de l'écriture des messages (j'avais un train à prendre)...

Il est possible que je n'aie pas réellement saisi la logique suivie, mais, dans l'ensemble, si erreur il y a, ce ne devrait pas être *trop* difficile à retrouver et à corriger.

Pour l'instant, je suis en cours, donc, désolé, mais je n'ai pas vraiment le temps d'y regarder maintenant

[Jean-Marc.Bourguet]

J'étais un peut pressé lors de l'écriture des messages (j'avais un train à prendre)...

Il est possible que je n'aie pas réellement saisi la logique suivie, mais, dans l'ensemble, si erreur il y a, ce ne devrait pas être *trop* difficile à retrouver et à corriger.

Pour l'instant, je suis en cours, donc, désolé, mais je n'ai pas vraiment le temps d'y regarder maintenant

Ta version de 17h01 que je n'avais pas vue corrige une des differences. La deuxieme peut se corriger en testant inserted a la fin de la boucle. Et on peut alors se passer du test if(m_vSprite.size() > 0).

[JolyLoic]

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.

Amusant, moi, l'interprétation sémentique me fait préférer l'interprétation inverse : J'ai tendance à voir l'exécution d'un programme comme le déplacement d'un curseur à l'intérieur du code, et dans ce cas, "return" s'interprète comme : "Retourne là d'où tu viens". Le fait d'associer une valeur à return signifiant "retourne là du tu viens, mais tu ne partiras pas les mains vides" me semble donc moins directe.

Pour ce qui est des autres arguments, je n'ai pour ma part pas de scrupules à utiliser return en milieu de fonction là où je trouve ça clair. En particulier, deux cas me viennent en tête :
- La sortie prématurée de boucles, où l'utilisation de return me semble souvent plus claire et directe que les alternatives qui demandent en général l'utilisation d'expression booléennes, ainsi que l'introduction de variables genre found.
- Les tests de validité des paramètres de la fonction, où mettre le "vrai" code de la fonction à l'intérieur des if ou else augmente inutilement à mon goût le niveau d'indentation.

[koala01]

J'estime personnellement qu'il y a moyen de s'en passer dans une très grosse majorité des cas, sans que cela ne nuise à la lisibilité ou aux performances du code...

Maintenant, autant bien se comprendre tout de suite:

J'ai eu suffisemment l'occasion de défendre mon point de vue en ce qui concerne l'utilisation de ce que j'appelle les "raccourcis" autorisés par C et par C++, et je n'ai nullement l'intention de relancer la polémique ici.

Je sais très bien que c'est autorisé par le langage, tout comme goto (par exemple), pour polémique qu'il soit reste autorisé par le langage (et non... il ne s'agit pas non plus de relancer celle-là )

Je ne dis donc pas qu'il *ne faut pas* utiliser le return sans valeur, je dis que je préfères m'en passer autant que possible.

Mais cela reste mon avis purement personnel... mais que je partage, et, je reste malgré tout conscient du fait qu'il y a des situations où l'on peut être contraint et forcé d'y avoir recours, voire, des situations dans lesquelles cela peut même être bénéfique d'y recourir...

Et je ne m'offusquerai aucunement si quelqu'un et d'avis contraire

[Médinoc]

Pour ce qui est des autres arguments, je n'ai pour ma part pas de scrupules à utiliser return en milieu de fonction là où je trouve ça clair. En particulier, deux cas me viennent en tête :
- La sortie prématurée de boucles, où l'utilisation de return me semble souvent plus claire et directe que les alternatives qui demandent en général l'utilisation d'expression booléennes, ainsi que l'introduction de variables genre found.
- Les tests de validité des paramètres de la fonction, où mettre le "vrai" code de la fonction à l'intérieur des if ou else augmente inutilement à mon goût le niveau d'indentation.

+1 pour les tests de validité des paramètres.
Sinon, on se retrouve avec du code pyramide...