Discussion :

[b Oo]

Bonjour je mets une fonction, dite moi laquelle vous préférez. (Ceci est tiré du livre Métier développeur : Kit de survie)

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
30
int maFonction(const char * filename, int taille)
{
  FILE * fp = fopen(filename, "rb");
  if(fp == 0)
  {
     printf("file not found");
     return ERR1;
  }
 
  char * buffer = new char[taille];
  if(buffer == 0)
  {
     fclose(fp);
     printf("out of memory");
     return ERR2;
  }
 
  int read = fread(buffer, 1, taille, fp);
  if(read != taille)
  {
     delete []buffer;
     fclose(fp);
     printf("read error");
     return ERR3;
  }
 
  delete []buffer;
  fclose(fp);
  return 0;
}

Voici la deuxième fonction écrite différemment :

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
 
int maFonction(const char * filename, int taille)
{
  int err=0;
  char * buffer = 0;
  FILE * fp = fopen(filename, "rb");
  if(fp == 0) { err=ERR1; goto Exit; }
 
  buffer = new char[taille];
  if(buffer == 0) { err=ERR2; goto Exit; }
 
  int read = fread(buffer, 1, taille, fp);
  if(read != taille) { err=ERR3; goto Exit; }
 
 Exit:
  if (buffer!=0) delete []buffer;
  if (fp!=0) fclose(fp);
  if(err !=0) printf("Error %d", err); 
 return err;
}

J'aimerais donc avoir vos avis sur les 2 et si l'utilisation de goto est utile et si oui dans quel cas.

Merci d'avance.


PS: je sais il y a du C avec du C++, mais ce code n'est pas de moi.

[Matthieu Brucher]

C'est du pur C, ton truc, y'a pas de C++ dedans - à part le new et le delete -. Avec le C++,on a encore moins besoin du goto grâce à la sémantique par objet, donc perso, jamais.

[Faiche]

que ce soit en C ou en C++ je n'ai jamais utilisé de goto.

De plus, vu que tu ne sais pas d'où tu viens, t'es obligé de refaire des tests, donc en l'occurence, ton goto n'apporte rien.

Enfin, je ne suis pas un expert, mais je dirais que faire des goto peut poser des problèmes d'accès à la mémoire, comme dans le cas des try catch, mais en pire.

Donc non seulement c'est sale mais en plus souvent dangereux.. Mais encore une fois ce n'est que mon avis

[koala01]

Je n'ai jamais mis un seul goto dans n'importe quel programme (meme pas en COBOL)...

Il faut dire que j'ai eu un prof qui nous menaçait (et qui l'aurait fait, j'en suis encore persuadé) de nous jeter par la fenetre si on utilisait goto

[Sylvain Togni]

En C++ il y a notamment l'idiome RAII qui permet de se passer de la plupart des gotos.

[koala01]

En C++ il y a notamment l'idiome RAII qui permet de se passer de la plupart des gotos.

Meme sans passer par l'idiome RAII, il y a parfaitement moyen de se passer des goto...

Le tout, c'est de mettre au point la bonne logique... Et peut etre d'utiliser la bonne technique de mise au point d'algorithmes...

J'en parle dans un autre sujet, mais, il est clair que si l'on crée l'algorithme en utilisant le flowchart, la tentation d'utiliser des goto sera bien plus importante...

Par contre, d'autres techniques (le nassichneiderman en tete) permettent de purement et simplement ignorer l'existence de cette commande "honnie"

[loufoque]

La seule utilité c'est pour combler l'absence d'un break n.

[koala01]

La seule utilité c'est pour combler l'absence d'un break n.

Et encore, dans le cadre d'une boucle, il y a souvent moyen, en la concevant différemment, de ne pas avoir besoin d'un break...

A titre tout à fait personnel, je n'utilise d'ailleurs le break que dans le cadre des switch ...case ... Mais on entre dans un autre débat

[Graffito]

je n'utilise d'ailleurs le break que dans le cadre des switch ...case

+1
et jamais de return en mileu de procedure.

[Matthieu Brucher]

+1
et jamais de return en mileu de procedure.

Toujours quand je fais une recherche, j'aime les breaks et les returns Avec le RAII, aucun problème de fuite mémoire ou qqch du genre.

[slylafone]

Tout pareil que miles.
J'aime bien les breaks et les returns. Beaucoup moins les gotos...

[koala01]

+1
et jamais de return en mileu de procedure.

Aussi... mais c'est parfois moins "sécurisant" à implémenter (nécessité de déclarer la variable renvoyée en début de fonction et de lui donner une valeur selon les résutlats des tests et des boucles, avec le risque de renvoyer une valeur "non définie" qui peut en résulter )

Cependant, je te plusotte également: une fonction n'est pas un autoroute sur lequel on choisit sa sortie : un point d'entrée et un point de sortie devrait rester la regle

Mais le débat dévie à nouveau... la question est: goto ou non?

[koala01]

Toujours quand je fais une recherche, j'aime les breaks et les returns Avec le RAII, aucun problème de fuite mémoire ou qqch du genre.

Tout pareil que miles.
J'aime bien les breaks et les returns. Beaucoup moins les gotos...

Bien que j'ai plussoté sur l'avis de graffito, je serais (cf mon poste précédent) beaucoup plus enclin à utiliser un return au milieu d'une fonction qu'un break dans une boucle...

Simplement parce que le break a tendance à "briser" la continuité, et à rendre une relecture (ou plutot une recompréhension de la lecture) plus difficile alors qu'il n'est pas *si difficile que cela* de s'en passer...

Mais bon, je ne fais qu'émetre un avis personnel, que je partage... sans obliger personne à etre d'accord

[slylafone]

Ok koala,

en faisant une recherche dans mes fichiers, je m'aperçois que je me sers rarement du break (sauf dans les switch case). Les rares fois où je l'utilise j'aurais pu faire autrement (et mieux en regardant de plus près).

Par contre les returns je me gave...

[b Oo]

C'est vrai que tous les professeurs ne veulent jamais entendre parlé du goto, et on comprend pourquoi.
En fait le procédural et l'objet sont des styles de programmations qui sont venus pour améliorer la lisibilité des programmes et pour que ce soit plus compréhensible que de programmer avec le goto. (et bien d'autres choses encore, mais ce n'est pas le sujet).

Je sais que le goto ne doit pas être utilisé dans de nombreux cas, et l'auteur ne le préconise que dans des cas similaires à celui-ci.
Si je vous posé cette question, c'est que moi aussi je ne vois pas pourquoi il utilise un goto.
Mais, je ne suis qu'étudiant et il y a une réelle différence entre ce qu'on voit à l'école et le développement. Donc je me demandais si sa technique est utilisé par des développeurs, apparemment non au vu de vos réponses.

[Graffito]

Bonjour,

Dans cet exemple, la solution 2 telle qu'on pourrait la coder pour eviter des paquets "if then else" donnerait :

Code :

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

1
2
3
4
5
  ...
  if (fp == 0) { err=ERR1; }
  if {err ==0) { buffer = new char[taille]; if (buffer == 0) { err=ERR2} }
  if {err ==0) { int read = fread(buffer, 1, taille, fp);  
                     if (read != taille) { err=ERR3 } }

[loufoque]

if {err ==0) { buffer = new char[taille]; if (buffer == 0) { err=ERR2} }

il faut mettre new(std::nothrow)

[Luc Hermitte]

+1
et jamais de return en mileu de procedure.

Vade retro bande de SESEistes.
Plus sérieusement. Nous sommes ici en C++, pas dans un langage incapable de collecter ses ressources de façon déterministe, ni dans un langage sans exceptions qui peuvent nous dérouter à tout endroit.
L'autre intérêt du SESE étant la lisibilité (et encore il faudra que l'on m'explique) qui est vite dégradée (par le SESE) quand une règle de qualité bien plus élémentaire (sur laquelle il agit en tant que contournement pervers) est respectée -> le nombre de ligne de code utile dans une fonction doit être raisonable en termes de nombre de pages d'écran (perso, j'aime bien tenir dans une demi).

Bref -> recherche avancée SESE et SEME.

Sinon, je me sers du "break", je me sers du "continue". Leur utilisation (hors application typique de recherche) est systématiquement documentée, en termes d'invariants parfois.

Je ne me suis plus servi du "goto" depuis mes premiers pas en basic. Il est toujours utilisé automatiquement dans les codes générés par (f)lex (-> machines à états). On le reconnait dans le Duff's device, même s'il s'agit d'un switch. A ce sujet, je suis tombé cette semaine sur un article de Knuth (?) qui faisait le point sur les erreurs techniques de notre profession. Il y targuait le switch de rejeton du goto, et racontait que cela ne valait pas mieux.
L'article se retrouve via lambda-the-ultimate.


Quand au pourquoi l'auteur utilise goto ? Ben il ne m'a pas vraiment l'air de connaitre le C++ ton auteur. Brûle ton livre, l'hiver approche, cela tombe bien.

[koala01]

(snip)
Je ne me suis plus servi du "goto" depuis mes premiers pas en basic. Il est toujours utilisé automatiquement dans les codes générés par (f)lex (-> machines à états). On le reconnait dans le Duff's device, même s'il s'agit d'un switch. A ce sujet, je suis tombé cette semaine sur un article de Knuth (?) qui faisait le point sur les erreurs techniques de notre profession. Il y targuait le switch de rejeton du goto, et racontait que cela ne valait pas mieux.
L'article se retrouve via lambda-the-ultimate.

Je n'ai surement pas la maitrise technique de Knuth(?), et je me garderai donc bien d'émettre le moindre jugement sur son assertion du point de vue du résultat obtenu...

Par contre, si l'on ne regarde que le code source, il n'y a franchement pas photo (sur un code correctement indenté, et présenté de manière cohérente, ca va de soi): un switch case est clairement plus lisible, à mon gout du moins, que la meme succession de goto

Quand au pourquoi l'auteur utilise goto ? Ben il ne m'a pas vraiment l'air de connaitre le C++ ton auteur. Brûle ton livre, l'hiver approche, cela tombe bien.

Sur ca, par contre, j'ai vraiment l'impression que tout le monde est d'accord

Ceci dit, et bien qu'il parle du C dans son intervention, il est des gens (L Tovalds, en l'occurence) qui font de véritables plaidoyers pour l'utilisation de goto dans certaines circonstances...

[Luc Hermitte]

Sur ca, par contre, j'ai vraiment l'impression que tout le monde est d'accord

Ceci dit, et bien qu'il parle du C dans son intervention, il est des gens (L Tovalds, en l'occurence) qui font de véritables plaidoyers pour l'utilisation de goto dans certaines circonstances...

OK. Pour définir une machine à état. Regrouper les erreurs en C. Pourquoi pas.

Si dans le bouquin il y a des "p = new ... ; if(p)" et des goto. L'auteur ne connait pas le C++. Sur le plan qualité de code C++ je serai plus que méfiant à l'égard de ce bouquin. Si maintenant c'est l'OP a traduit des malloc en new. OK. Soit. C'est une façon de faire ...en C.

Le problème, ce n'est pas le goto. C'est de faire des bidouilles en C++ qui complexifient le code et qui sont à côté de la plaque -- le comportement par défaut du new post-98 est de lever une exception, et les règles qualité sérieuses poussent vers les abstractions RAII comme les vecteurs.