Discussion :

[peter27x]

En Delphi, on ne peut pas faire un calcul, puis faire quelque chose en fonction du résultat du calcul sans refaire un test après le calcul.

Même si ton calcul est fait dans une fonction ? Ex :

Code :

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

f_calcul (x,y,z) : integer;

et que ton ton test de redirection est fait directement sur le retour de la fonction ? Ex :

Code :

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

if f_calcul(a,b,c) = 0 then ...

?

NB : On peut supposer que la fonction mette le résultat dans une variable passée par référence, ou bien dans un champ d'un objet visible depuis la fonction, ou que sais je d'autre...

NB2 : tu me diras peut être que tout cela revient à faire le calcul puis le test ensuite... mais n'est ce pas aussi le cas avec ton Jump if Zero issu de l'ASM ?

[Gilbert Geyer]

Bonjour,

Moi je dirais simplement que puisque le GoTo et les labels existent on peut s'en servir si on le veut (et une fois qu'on l'a choisi, ben on se débrouille avec lui ou eux) ... par contre je me demande s'il existe au moins un seul cas de figure où il serait encore indispensable, mais vu la remarque de ShaiLeTroll au sujet des fonctions j'arrête de torturer mes neurones pour dénicher un tel cas. (je parle uniquement du GoTo et non des jump de l'Asm en ligne de Delphi.)

Ceci étant je me verrais mal utiliser des labels du style 1415, 1872 etc... c'est vraiment pas "parlant".

A+.

[peter27x]

Bonjour,

Moi je dirais simplement que puisque le GoTo et les labels existent on peut s'en servir si on le veut (et une fois qu'on l'a choisi, ben on se débrouille avec lui ou eux) ... par contre je me demande s'il existe au moins un seul cas de figure où il serait encore indispensable, mais vu la remarque de ShaiLeTroll au sujet des fonctions j'arrête de torturer mes neurones pour dénicher un tel cas. (je parle uniquement du GoTo et non des jump de l'Asm en ligne de Delphi.)

Ceci étant je me verrais mal utiliser des labels du style 1415, 1872 etc... c'est vraiment pas "parlant".

A+.

Voilà, chacun voit midi à sa porte.

Et puis je suis sûr qu'il existe des programmes clairement indentés, logiques et aisés à lire utilisant 2,3 petits goto (nul n'est parfait ), et des programmes non indentés, à la logique torturées et illisibles n'utilisant pas de goto... Alors bon, après, goto or not goto... on aime ou on aime pas.

[Kaféine]

Just for fun

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
31
32
33
34
35
36
37
 
procedure TForm1.Test(UnFlag: Boolean);
begin
  if UnFlag then
    Test1
  else
    Test2;
end;
 
procedure TForm1.Test1;
begin
  ShowMessage('Test1');
end;
 
procedure TForm1.Test2;
begin
  ShowMessage('Test2');
end;
 
procedure TForm1.TestGOTO(UnFlag: Boolean);
label Test1, Test2, Exit;
begin
  if UnFlag then
    goto Test1
  else
    goto Test2;
 
Test1:
  ShowMessage('Test1');
  //...
  goto Exit;
 
Test2:
  ShowMessage('Test2');
  //...
Exit:
end;

dans ce cas précis Test et TestGOTO sont identiques non?
on peut aussi coller Test1 et Test2 dans Test...

[peter27x]

Just for fun +++++

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
procedure TForm1.TestGOTO(UnFlag: Boolean);
label 1,2,3,4,5,6,7,8;
begin
1:  if UnFlag then
2:    goto 5
3:  else
4:    goto 7;
5:  ShowMessage('Test1');
6:  goto 8;
7:  ShowMessage('Test2');
8:  
end;

Version améliorée:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure TForm1.TestGOTO(UnFlag: Boolean);
label 1,2,3,4,5,6,7,8,9,10;
begin
1: goto 3;
2: Exit;
3:  if UnFlag then
4:    goto 7
5:  else
6:    goto 9;
7:  ShowMessage('Test1');
8:  goto 10;
9:  ShowMessage('Test2');
10:  goto 2;
end;

[Franck SORIANO]

Non.

Dans TestGOTO, tu dois faire des goto EXIT que tu peux facilement oublier et qui nuiront à la maintenabilité de ton code.
Qui plus est, quand tu lis "goto Exit" tu ne sais pas réellement ce que tu vas trouver à l'étiquette tant que tu n'es pas aller voir ! Donc tu ne sais pas ce qui se passe sur le goto Exit. Dans la première forme tu vois tout de suite que la procédure est terminée. Ce qui vient aussi du fait que le code avec les goto a engendré une méthode beaucoup plus longue, si bien qu'on est obligé d'aller scroller pour voir ce qui se passe après...

[Kaféine]

Evidemment...

mais indépendamment des problèmes de maintenabilité, lisibilité du code...
elles sont fonctionnellement identiques enfin elles produisent le même résultat notamment dans ce cas précis qui est trés simple.

[Mac LAK]

Le problème, c'est que ce n'est pas parce qu'une fonctionnalité fait partie du langage qu'il est souhaitable / sain de l'utiliser...

Les chaînes AZT ? Nécessaire pour s'interfacer avec l'API Win32, et la plupart des DLL en C/C++...
Les pointeurs ? Même raison.
Les goto ? Aucune "bonne" raison de l'utiliser par contre.

Delphi / Pascal est un langage qui permet aussi bien de s'approcher du bas niveau que d'aller à assez haut niveau. Il ne faut donc pas jeter la pierre sur les quelques éléments requis pour cette partie "bas niveau" du langage, c'est quand même ce qui fait sa force.

Par contre, le "goto" est une horreur algorithmique : même en BASIC, on préconisait lourdement le "gosub" en lieu et place du "goto", il faudrait voir à s'en rappeler.

Certes, il existe quelques (très) rares cas où il peut s'avérer utile... Notamment pour sortir par exemple de deux boucles "for" imbriquées. Mais cela reste du code "crade", car si c'est "nécessaire", c'est que l'algo initial (et notamment ses points de rupture) ont été mal pensés.

Mais des "goto" en Pascal, c'est comme en C, ou l'usage abusif de macros en C, ou ne JAMAIS libérer ses propres ressources sous prétexte que l'on a un GC : c'est crade, cela rend le code difficilement maintenable et c'est la porte ouvert à pas mal d'abus.
Car une fois qu'on a pris de mauvaises habitudes, il est difficile de s'en défaire... Voire de réussir à "penser" correctement, suivant les paradigmes corrects du langage.

[peter27x]

Certes, il existe quelques (très) rares cas où il peut s'avérer utile... Notamment pour sortir par exemple de deux boucles "for" imbriquées.

Pas du tout, suffit d'avoir un booléen que la 2° boucle for viendra mettre à true avant son break. Ainsi, dans le 1er for, à la fin du for imbriqué, on viendra juste tester ce booléen et faire un break s'il est à true.

[Paul TOTH]

Pas du tout, suffit d'avoir un booléen que la 2° boucle for viendra mettre à true avant son break. Ainsi, dans le 1er for, à la fin du for imbriqué, on viendra juste tester ce booléen et faire un break s'il est à true.

... ou de placer l'ensemble dans une sous-fonction et de quitter par un Exit

c'est souvent ce que je fais car un code avec deux boucles imbriquées et des conditions de sorties commune devient moins lisible qu'une fonction bien nommée

[peter27x]

... ou de placer l'ensemble dans une sous-fonction et de quitter par un Exit

c'est souvent ce que je fais car un code avec deux boucles imbriquées et des conditions de sorties commune devient moins lisible qu'une fonction bien nommée

Oui mais là on ne se plaçait pas dans le contexte d'une fonction dédiée au duo de FOR (tea for two, and two for tea...).

Mais sinon finalement, ton exit ne serait il pas un goto avec un costard cravate, rasé de prés et embaumant l'Aqua Velva ?

[Kaféine]

Salut,

Les chaînes AZT

AZT, c'est pas un médicament contre le sida ca?

Par contre, le "goto" est une horreur algorithmique ...

le seul problème à mon sens, et maintes fois répétés dans ce topic, c'est que le goto peut rendre le code difficile à lire et à gérer. dans mon job précédent certain voulais interdire le "exit" pour les mêmes raisons...

Mais cela reste du code "crade"...

J'ai déjà vu des "codes crades" sans goto
un "code crade" reste une notion subjective. un code crade pour toi ne l'ai pas forcément pour un autre notamment celui qui en est l'auteur

[Just-Soft]

Mais ce n'était qu'un exemple de bon usage que Mac LAK a donné. Enfin, ce qu'il faut retenir de cette discussion c'est que l'alternative du GOTO, en général, existe.

[Kaféine]

ce qu'il faut retenir de cette discussion c'est que l'alternative du GOTO, en général, existe.

tout à fait !

Oui en général, mais l'alternative n'existe pas toujours sinon Mr le responsable du langage pourrait tout simplement supprimer l'instruction goto du compilateur or elle persiste... à méditer

et je finirais sur une locution latine:
"cogito ebarerum citoe sed barum"
(ca veut rien dire mais ca fait classe)

[ShaiLeTroll]

Le GOTO, malgré ce que l'on peut dire, lorsque l'on lit l'exemple de l'aide de D7 par exemple, cela montre 3 boucles for X, Y, Z, ... à traduire sans le GOTO, cela nécessiterait des flags pour gérer la rupture à chaque niveau de boucle, ou alors, mettre ce bloc dans une sous-fonction et utiliser Exit ... et là on ne peut rien dire, c'est finalement de même niveau que Break ou Continue ... et évite des itérations et tests inutiles, cela simplifie le code ! suffit juste de bien un petit commentaire d'avertissement pour attirer l'oeil (comme je le ferais sur Exit, Break ou Continue, qui ne sont pas n'ont plus terrible en terme de lisibilité !)

et je finirais sur une locution latine:
"cogito ebarerum citoe sed barum"
(ca veut rien dire mais ca fait classe)

"Tempora mori, tempora mundis recorda". Voilà. Et bien ça, par exemple, ça veut absolument rien dire, mais l’effet reste le même ... Loth

[Paul TOTH]

tient c'est pas bête ça, que dit l'aide en ligne ?

L'utilisation de l'instruction goto est généralement déconseillée en programmation structurée. Elle peut néanmoins être utilisée dans certains cas pour sortir de boucles imbriquées comme dans l'exemple suivant :

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
 
procedure TrouverPremiereReponse;
 
var X, Y, Z, Compteur: Integer;
label ReponseTrouvee;
begin
  Compteur := UneConstante;
  for X := 1 to Compteur do
    for Y := 1 to Compteur do
      for Z := 1 to Compteur do
        if ... { une condition portant sur X, Y et Z } then
          goto ReponseTrouvee;
 
  ... {code à exécuter si aucune réponse n'est trouvée }
  Exit;
 
  ReponseTrouvee:
    ... { code à exécuter si une réponse est trouvée }
end;

Remarquez que l'instruction goto sert à sortir de la boucle imbriquée. Ne rentrez jamais dans une boucle ou dans d'autres instructions structurées car cela peut donner des résultats imprévisibles.

et ma version de ce code

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
 
function TrouveUneReponse: Boolean;
var
  X, Y, Z, Compteur: Integer;
begin
  Result = True;
  Compteur := UneConstante;
  for X := 1 to Compteur do
    for Y := 1 to Compteur do
      for Z := 1 to Compteur do
        if ... { une condition portant sur X, Y et Z } then
         Exit;
  Result := False;
end;
 
procedure TrouverPremiereReponse;
begin
  if TrouveUneReponse then
    { code à exécuter si une réponse est trouvée }
  else
    {code à exécuter si aucune réponse n'est trouvée }
end;

[peter27x]

Ou en latin dans le texte : Paulus Tothaes Genissimium es.

[Gilbert Geyer]

Bonjour,

C'est effectivement "Genissimium" : On remplace un GoTo par un EXIT comme si le GoTo avait la peste.

Sacré GoTo t'en fais bien cliquer les claviers ici.

A+.

[Mac LAK]

Pas du tout, suffit d'avoir un booléen que la 2° boucle for viendra mettre à true avant son break. Ainsi, dans le 1er for, à la fin du for imbriqué, on viendra juste tester ce booléen et faire un break s'il est à true.

Tu noteras que j'ai dit "utile"... Et non pas "nécessaire", ni "indispensable"...

Mais sinon finalement, ton exit ne serait il pas un goto avec un costard cravate, rasé de prés et embaumant l'Aqua Velva ?

Surtout, il est sans erreurs, uniquement sortant, et compatibles avec les exceptions et clauses spéciales genre "Finally"...

AZT, c'est pas un médicament contre le sida ca?

Hum... Celle-là, tu aurais pu la garder pour toi, faut pas confondre humour noir et mauvais goût.
AZT = A Zéro Terminal, traduit en PChar sous Delphi notamment.

le seul problème à mon sens, et maintes fois répétés dans ce topic, c'est que le goto peut rendre le code difficile à lire et à gérer. dans mon job précédent certain voulais interdire le "exit" pour les mêmes raisons...

Sauf qu'un Break, Continue ou Exit est uniquement sortant, ce que ne garantit justement pas un "goto" qui peut tout à fait te faire rentrer en plein milieu d'une boucle, ou n'importe où de façon générale, et peut donc causer de sévères failles d'algo... C'est pas la peine de s'interdire le "Exit" pour faire du SESE si c'est pour le truffer de "goto" à l'intérieur !

un "code crade" reste une notion subjective. un code crade pour toi ne l'ai pas forcément pour un autre notamment celui qui en est l'auteur

Certes. Sauf que là, quand même, 95% au moins des développeurs vont trouver ça crade.
Sur des instructions de rupture d'exécution, par contre, tu arrives en général à 50/50 : la moitié est "pour" pour des raisons de performance, l'autre moitié est "contre" pour des raisons de SESE.

Oui en général, mais l'alternative n'existe pas toujours sinon Mr le responsable du langage pourrait tout simplement supprimer l'instruction goto du compilateur or elle persiste... à méditer

Rétrocompatibilité, tout simplement, et sur de très très rares cas au sein de la VCL, dans les parties ne gérant pas les exceptions notamment...
Or, tu n'écris pas de VCL tous les jours, loin de là. Ce n'est pas parce que quelque chose fait partie du langage qu'il est bon d'en user, et encore moins d'en abuser.

Quant à l'alternative en code utilisateur... Bah, montres-nous un exemple, on se fera un plaisir de te la faire en programmation structurée "normale"...
Seul impératif : la fonction exemple devra faire quelque chose de "réel", et bien sûr devra être décrit / documenté...

[Kaféine]

salut,

Désolé si j'ai heurté ta sensibilité mais bon je connais pas tous les sigles AZT notamment...(maintenant je sais)

C'est pas la peine de s'interdire le "Exit" pour faire du SESE si c'est pour le truffer de "goto" à l'intérieur

d'abord il faut que tu saches que je n'utilise pas de goto dans mon code.
On peut toutefois remarquer qu'à chaque fois que l'on parle de cette instruction ca suscite des débats philosophiques et c'est ce qui m'amuse.

Pour ce qui concerne l'anecdote du exit, (oui il execute le bloc finally oui a condition qu'il se trouve dans le bloc try en vis à vis), c'était pour souligner le fait que le exit peut poser des problèmes de lecture du code pour certains. Evidemment les goto etaient interdits et envisagé d'interdire le exit aussi.

Rétrocompatibilité, je veux bien.....
Depuis le temps il aurait pu le deprecated.
d'autant plus qu'en parcourant les sources de la VCL le goto apparait dans la librairie Indy, GifImage et dans un fichier MXDSSQRY.
Si je suis ton raisonnement, ils peuvent surement s'en passer et c'est a mon avis le cas sauf que les developpeurs qui ont codé ça connaisse l'instruction, ses risques, ses faiblesses et n'ont pas jugé utile de modifier le code.

On peut toujours se passer de goto ! la question est donc pourquoi il ne le supprime pas c'est tout.