Discussion :

[contremaitre]

Je venais d'ecrire la fonction ci-dessous que je suis tombé sur :
http://emmanuel-delahaye.developpez.com/goret.htm

Force 8
* Plus d'un return par fonction

Cette fonction retourne la distance minimum entre :
- p + d
et
- centre

Sachant que -1 représente l'infini.

Il me semble que les return évitent des tests inutiles.

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
 
static inline int min_dist(int centre, int p, int d) {
    if(centre == -1) {
	if(p == -1) {
	    return centre; //j'aurai pu ecrire return -1 c'est pareil
	}
	return p+d;
    }
    if(p == -1) {
	return centre;
    }
    if(p+d < centre) {
	return p+d;
    }
    return centre;
}

Accessoirement je ne comprends pas trop ceci aussi :

Utilisation du type int ou long pour les index.

J'ai toujours vu des int pour les index, quel est le problème sachant que la manipulation d'un int n'est pas plus lente qu'un autre type?

[DaZumba]

Je venais d'ecrire la fonction ci-dessous que je suis tombé sur :
http://emmanuel-delahaye.developpez.com/goret.htm

Cette page contient l'avis personnel d'Emmanuel Delahaye. Certains conseils relevent du bon sens, d'autres sont plus une question de style. N'avoir qu'un seul return par fonction est une question de style. Tu fais ce que tu veux.

Dans ton cas, n'avoir qu'un seul return est trivial:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
static inline int min_dist(int centre, int p, int d) {
   int ret = centre;
 
    if((centre == -1 && p != -1) ||
       (p+d < centre))
    {
	ret = p+d;
    }
    return ret;
}

[Thierry Chappuis]

Personnellement, je trouve que utiliser une seule instruction return par fonction clarifie le code. En effet, selon les principes fondamentaux de la programmation structurée, une fonction doit posséder un seul point d'entrée et un seul point de sortie. Mais ne soyons pas dogmatiques, et comme le dit très bien DaZumba, c'est essentiellement une question de style et de goût personnel. D'autres personnes trouvent que la présence de multiples return clarifie le code, moi pas.

En ce qui concerne les indices, j'utilise généralement le type size_t.

Thierry

[contremaitre]

Dans ton cas, n'avoir qu'un seul return est trivial:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
static inline int min_dist(int centre, int p, int d) {
   int ret = centre;
 
    if((centre == -1 && p != -1) ||
       (p+d < centre))
    {
	ret = p+d;
    }
    return ret;
}

Pas si trivial que ca car il faut gerer l'infini représenté par -1.
Ici, si p == -1 et centre > p+d tu retournes p+d ce qui sera faux.

[DaZumba]

Pas si trivial que ca car il faut gerer l'infini représenté par -1.
Ici, si p == -1 et centre > p+d tu retournes p+d ce qui sera faux.

Ah oui, je me suis fait avoir pour le troisieme return

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
static inline int min_dist(int centre, int p, int d)
{
   int ret = centre;
 
    if(p != -1 && (centre == -1 || p+d < centre))
    {
	ret = p+d;
    }
    return ret;
}

[pfeuh]

Salut,

Dans l'embarqué, l'optimisation du code est un critères important dans le choix d'un compilateur.

Pour une fonction à plusieurs return, le débogueur sera incapable de suivre pas à pas le code puisque qu'il est très fortement modifié par l'optimiseur, en particulier les return qui risquent de se transformer en un seul return. Ce qui fait souvent dire que le débogueur ne marche pas, ce qui est faux, puisqu'il suffit de désactiver l'optimiseur pour que tout rentre dans l'ordre.

Il en est de même pour les variables modifiées mais non lues que l'on crée pour déboguer. Si elle ne sont jamais lues, l'optimiseur les supprimera purement et simplement du code d'où là aussi un comportement indéterminé en mode pas à pas.

A+

Pfeuh

[mr_samurai]

je vous avoue que c'est la première fois que j'entends dire que plusieurs return dans une même fonction était déconseillé .

j'ai souvent plusieurs return dans mes méthodes pour plusieurs raisons. Entre autre gérer les cas particuliers (variable d'entrée mal conditionner ou cas intraitable).

Je trouve mieux un :

Code :

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

1
2
3
4
5
6
7
double  inverse(double x)
{
  if(x == 0.0) {
    return 0.0;
  }
  return 1/x ;
}

que :

Code :

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

1
2
3
4
5
6
7
8
double  inverse(double x)
{
  double y = 0.0;
  if(x != 0.0) {
    y = 1/x;
  }
  return y;
}

++

[Melem]

L'objectif c'est pas d'avoir un ou plusieurs return mais du code lisible. Des deux écritures on préferera donc celle qui rendra le code plus lisible. Ca peut être l'un, ça peut être l'autre ...

[diogene]

mr_samurai :

j'ai souvent plusieurs return dans mes méthodes pour plusieurs raisons. Entre autre gérer les cas particuliers (variable d'entrée mal conditionner ou cas intraitable).

Dans ce cas tu as tes return en début de fonction où leur présence est facilement détectable et interprétable par le lecteur : C'est en quelque sorte une phase de validation de la fonction. Ca peut éviter d'imbriquer des blocs qui peuvent alourdir la lisibilité de la "partie essentielle" de la fonction. Je n'ai personnellement rien à reprocher à cette méthode.
Par contre, je suis beaucoup plus réticent sur le fait d'avoir ensuite d'autres return "cachés" dans les blocs de la "partie essentielle" de la fonction.

[souviron34]

Je trouve mieux un :

Code :

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

1
2
3
4
5
6
7
double  inverse(double x)
{
  if(x == 0.0) {
    return 0.0;
  }
  return 1/x ;
}

que :

Code :

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

1
2
3
4
5
6
7
8
double  inverse(double x)
{
  double y = 0.0;
  if(x != 0.0) {
    y = 1/x;
  }
  return y;
}

++

et :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
double  inverse(double x)
{
  double res ;
 
  if(x == 0.0)
       res= 0.0;
  else 
       res = 1/x ;
 
  return res ;
}

Sinon, comme il a ete dit, tout depend du contexte, d ela fonction, de sa longueur, etc etc...

Quant a la question d'optimisation, ON NE VAS PAS REVENIR DESSUS : a part cas tres tres tres particuliers, ce genre de choses compelxifient et n'accelerent pas.... L'optimisation vient a 99.99999 % des cas de l'algo, pas de son ecriture...

[mr_samurai]

oki, je vois bien ce que vous voulez dire.

Je suis d'accord avec vous sur ce point. Personnellement, je n'utilise return que pour la validation de entrées, et des cas de switch.

[hegros]

beh moi ca dépend des cas, prenons l'exemple d ela bibliothéque standard la fonction strcmp.

voici une tentative de réécriture de la fonction, est-ce que vous saurez faire plus lisible avec 1 return

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
static inline int my_strcmp(const char * const s1,const char * const s2) {
 
    int i;
    i=0;
    while(s1[i]!='\0' && s2[i]!='\0') {
        if(s1[i]<s2[i])
            return -1; /* on quitte la fonction */
        else
            if (s1[i]>s2[i])
                return 1;
 
        /* caractère identique */
        i++;
    }
 
 
    /* causes de la sortie de boucle */
    if(s1[i]!='\0' && s2[i]=='\0')
        return 1;
               else if(s1[i]=='\0' && s2[i]!='\0')
                   return -1;
 
    return 0;
 
}

Le risque avec plusieurs return est que tu oublies un cas ce qui fait que pendant l'execution ta fonction ne renvoi rien du tout, normalement avec les options du compilateur ces warnings sont détectables

[souviron34]

oki, je vois bien ce que vous voulez dire.

Je suis d'accord avec vous sur ce point. Personnellement, je n'utilise return que pour la validation de entrées, et des cas de switch.

pour les switch, au contraire, c'est tellement facile de mettre un statut et de retourner une seule fois le statut a la fin...

La validation d'entrees, peut-etre...

C'est a mon avis surtout utilisable en debut de fonction necessitant soit un grand nombre de parametres ou d'allocations, qui ferait trop de if pour tout prendre en compte ... soit une serie de conditions rendant caduqye le traitement situe plus bas...

[DaZumba]

beh moi ca dépend des cas, prenons l'exemple d ela bibliothéque standard la fonction strcmp.

voici une tentative de réécriture de la fonction, est-ce que vous saurez faire plus lisible avec 1 return

Hmm:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
int my_strcmp(const char *s1, const char *s2)
{
  while (*s1 != '\0' && *s1 == *s2)
  {
    s1++;
    s2++;
  }
 
  return (*(unsigned char *) s1) - (*(unsigned char *) s2);
}

(note que strcmp() ne renvoie pas forcement -1, 0, ou 1).

EDIT: Correction (pointeurs const dans le prototype retirés.)

[ram-0000]

L'objectif c'est pas d'avoir un ou plusieurs return mais du code lisible. Des deux écritures on préferera donc celle qui rendra le code plus lisible. Ca peut être l'un, ça peut être l'autre ...

+1

[hegros]

**

[Sve@r]

Accessoirement je ne comprends pas trop ceci aussi :

Utilisation du type int ou long pour les index.

J'ai toujours vu des int pour les index, quel est le problème sachant que la manipulation d'un int n'est pas plus lente qu'un autre type?

Ce n'est pas une question de lenteur mais de compatibilité ascendante. Aujourd'hui la taille maximale d'un tableau dépasse le simple int et est de l'ordre du long donc déjà pour que ton code fonctionne encore dans les cas extrèmes, il te faut remplacer tes "int i" par des "long i". Et accessoirement étant donné qu'un indice est toujours positif, le unsigned peut être utile.
Maintenant que se passera-t-il demain lorsque les architectures 64 deviendront un standard et que ton tableau pourra atteindre le 2^64 bits ? Faudra remplacer tes long par le nouveau type qui va bien.

Pour éviter ce problème, il existe le type "size_t" qui est suffisemment grand pour gérer l'ensemble d'un tableau aujourd'hui. Et si demain l'ensemble change, le type sera modifié en conséquence. Donc si tu définis tes index de type "size_t" ton code suivra l'évolution des systèmes sans que t'aies besoin de le modifier.

Là où parfois j'ai des problèmes, c'est quand je définis une fonction qui renvoie l'index d'un élément du tableau. La fonction est donc de type size_t. Mais quand elle ne trouve pas l'élément voulu il faut qu'elle renvoie une valeur spéciale. Mais je peux pas lui faire renvoyer "-1" car il n'est pas de type size_t (unsigned long).

[Médinoc]

Tu peux toujours retourner SIZE_MAX, défini dans limits.h...

[Emmanuel Delahaye]

Tu peux toujours retourner SIZE_MAX, défini dans limits.h...

ou ((size_t)-1) si tu n'as pas C99...

[dapounet]

Aujourd'hui la taille maximale d'un tableau dépasse le simple int et est de l'ordre du long donc déjà pour que ton code fonctionne encore dans les cas extrèmes, il te faut remplacer tes "int i" par des "long i". Et accessoirement étant donné qu'un indice est toujours positif, le unsigned peut être utile.
Maintenant que se passera-t-il demain lorsque les architectures 64 deviendront un standard et que ton tableau pourra atteindre le 2^64 bits ? Faudra remplacer tes long par le nouveau type qui va bien.

Ça dépend d'à quoi sert le tableau. Si il contient des trucs sur les mois de l'année tu crois vraiment qu'il risque un jour de contenir plus de 2^16 éléments ? Personnellement j'utilise presque tout le temps unsigned int.
Pour le moment en mode 64 bits on n'a "que" 48 bits d'adressage. Tu te rends compte de la quantité que ça fait 2^64 ?