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

++

[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

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

[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 ?

[Médinoc]

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

[Sve@r]

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

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

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

[dapounet]

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

C'est totalement dependant de la plate-forme.

Tu parles de plate-forme au sens général ou des implémentations x86-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).

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.

[Sve@r]

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

Personnellement j'utilise presque tout le temps unsigned int.

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

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

[gl]

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

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.

[gl]

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

C'est totalement dependant de la plate-forme.

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

[InOCamlWeTrust]

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 !