plusieurs return dans une fonction?

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

Citation:

---

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:

---

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 :

Citation:

---

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?

Citation:

---

Envoyé par pasdeface

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:

---

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; }

---

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

Citation:

---

Envoyé par DaZumba

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

Code:

---

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.

Citation:

---

Envoyé par pasdeface

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:

---

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; }

---

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

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é :aie: .

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:

---

1 2 3 4 5 6 7

double inverse(double x) { if(x == 0.0) { return 0.0; } return 1/x ; }

---

que :

Code:

---

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; }

---

++

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

mr_samurai :

Citation:

---

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.

Citation:

---

Envoyé par mr_samurai

Je trouve mieux un :

Code:

---

1 2 3 4 5 6 7

double inverse(double x) { if(x == 0.0) { return 0.0; } return 1/x ; }

---

que :

Code:

---

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:

---

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

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.

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

Code:

---

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

Citation:

---

Envoyé par 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.

---

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

Citation:

---

Envoyé par 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

---

Hmm:

Code:

---

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

Citation:

---

Envoyé par 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 ...

---

+1

**

Citation:

---

Envoyé par pasdeface

Accessoirement je ne comprends pas trop ceci aussi :

Citation:

---

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

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

Citation:

---

Envoyé par Médinoc

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

---

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

Citation:

---

Envoyé par Sve@r

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 ?

Je trouve que ça va quand même plus vite d'utiliser directement un size_t.

Citation:

---

Envoyé par dapounet

Ça dépend d'à quoi sert le tableau. Si il contient des trucs sur les mois de l'année

---

Ben c'est évident. Si la taille est définitivement figée dans un ensemble immuable on va un peu optimiser la taille de l'indice. T'étais vraiment obligé de venir chercher un exemple aussi nul pour me prouver que size_t est inutile ??? size_t est un "outi"l qui te "permet de". Si tu penses que tu n'en as pas besoin parce que TOUS tes tableaux que t'as jamais programmés et que tu programmeras jamais ne dépasseront jamais le chiffre 12, ben autant rester à l'unsigned char dans tes indices.

Citation:

---

Envoyé par dapounet

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.

---

T'es totalement libre. Je répondais juste à une question (qui n'es pas de toi) qui demandait "pourquoi on dit que...". Je ne t'ai jamais dit comment programmer. Mais je remarque quand-même que t'as pensé à l'usigned ce qui dénote déjà une certaine recherche. T'aurais pu pousser cette recherche jusqu'au bout et tu serais arrivé au size_t...

Citation:

---

Envoyé par dapounet

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 ?

---

Ca fait que là t'es tranquille !!!

Citation:

---

Envoyé par dapounet

Pour le moment en mode 64 bits on n'a "que" 48 bits d'adressage.

---

C'est totalement dependant de la plate-forme.

Citation:

---

Envoyé par dapounet

Tu te rends compte de la quantité que ça fait 2^64 ?

---

Si ce n'est qu'il n'y a aucune garantie que sur une architecture 64 bits un unsigned int fasse 64bits. Il peut tout a fait en faire seulement 16 (pour rappel, la plage garantie par la norme de unsigned int est 0 à 65535).

Concernant le nombre de return par fonction, moi je dis qu'il en faut trois ; non pas deux, ni quatre, mais trois.

- un pour faire terminer la fonction
- un pour rendre le code joli
- et un autre pour rendre le code lisible

Si quelqu'un affirme le contraire, alors il ne sait pas programmer !

Citation:

---

Envoyé par Sve@r

T'étais vraiment obligé de venir chercher un exemple aussi nul pour me prouver que size_t est inutile ???

---

J'aimerais quand même bien savoir où j'ai voulu dire que size_t est inutile et à quoi ça peut servir de l'utiliser systématiquement pour les indices puisque c'est la question. Ne me dis pas qu'on utilise à tout bout de champ des tableaux de plus de 64K...

Citation:

---

Envoyé par gl

C'est totalement dependant de la plate-forme.

---

Tu parles de plate-forme au sens général ou des implémentations x86-64 ?

Citation:

---

Envoyé par gl

Si ce n'est qu'il n'y a aucune garantie que sur une architecture 64 bits un unsigned int fasse 64bits. Il peut tout a fait en faire seulement 16 (pour rappel, la plage garantie par la norme de unsigned int est 0 à 65535).

---

En x86-64 un int fait 32 bits. Je me suis exprimé dans le désordre mais je voulais simplement dire que c'est complètement utopique de parler de tableaux de 2^64 éléments.

Citation:

---

Envoyé par dapounet

J'aimerais quand même bien savoir où j'ai voulu dire que size_t est inutile

---

C'est ce que j'ai compris quand j'ai lu ceci

Citation:

---

Personnellement j'utilise presque tout le temps unsigned int.

---

Citation:

---

Envoyé par dapounet

et à quoi ça peut servir de l'utiliser systématiquement pour les indices puisque c'est la question.

---

Ben simplement parce que c'est un outil fait pour ça. On peut faire sans et prendre un risque, ou faire avec et n'en prendre aucun. On peut aussi faire sans "parfois" et malgré cela ne pas prendre de risque "dans ce cas précis" (comme pour les 12 mois de l'année) mais ce cas est lui-aussi assez rare...

Citation:

---

Envoyé par dapounet

Ne me dis pas qu'on utilise à tout bout de champ des tableaux de plus de 64K...

---

Non mais à la limite je m'en fouts. Je sais que si mon tableau dépasse 64K éléments, mon code fonctionnera toujours...

Citation:

---

Envoyé par dapounet

Tu parles de plate-forme au sens général ou des implémentations x86-64 ?

---

De maniere generale, la taille du bus d'adresse est totalement dependante de la plateforme.
De fait utiliser cette justification pour choisir la taille d'un type restreint le programme a une gamme de plateforme precise et donc limite la portabilite et rends de ce fait ce programme moins evolutible (Ce qui par ailleurs n'est pas necessairement un probleme, ca depends du contexte).

Citation:

---

Envoyé par dapounet

En x86-64 un int fait 32 bits. Je me suis exprimé dans le désordre mais je voulais simplement dire que c'est complètement utopique de parler de tableaux de 2^64 éléments.

---

De maniere portable, un unsigned int ne permet de stocker que des valeurs comprises entre 0 à 65535, ce qui peut etre certes suffisant dans certains cas mais on atteinds vite les limites.
Supposer que la taille sera de 32 bits limite inutilement la portabilite du programme.

ben c'est un bon exemple la fonction strcmp

Code:

---

1 2 3 4 5 6 7 8

int my_strcmp(char *a, char *b) { while(1) { if (*a != *b) return *a - *b; if (*a == 0) return 0; a++; b++; } }

---