Discussion :

[PeD012]

Bonjour,

est il possible de modifier la valeur d'un label et donc de conditionner un goto.

Exemple

Code :

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

&label = "test1"

et dans le code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
     .....
      pppp
      pppp
      GoTo &label
 
test1:
      xxxx
      xxxx
      xxxx
 
test2:
      yyyy
      yyyy

Une autre fois, suivant l'une ou l'autre condition extérieure, il y aurait

Code :

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

&label = "test2"

Merci de votre avis implaccable

Pierre

Note : cela existe dans d'autres langages, au moins en PL/I.

[StringBuilder]

Bonjour,

GOTO date de l'age d'or du Basic, notamment avec QBasic sous MS-DOS.

Pour des raisons proches de l'inexplicable, ce mot clé a été conservé dans certains langages modernes.

Mais une chose est certaine : il ne faut JAMAIS l'utiliser.

Les langages modernes que sont VB.NET (et même VB6 à l'époque de Windows 95) peuvent parfaitement s'en passer.
Et même à l'époque de QBasic, on pouvait déjà s'en passer d'ailleurs...

Repensez votre programme pour ne pas avoir à faire ces horribles GOTO.

[PeD012]

Merci pour la réponse, Stringbuilder.

Je ne vais pas entrer dans une guerre sur ce sujet. Votre programmation structurée peut certainement se passer des "goto" et vous faites bien.

Ma programmation l'a trouvé parfois utile, pas tout le temps loin de là.

Simplement aussi beaucoup de goto sont déguisés. Un call n'est finalement qu'un branch et un return, donc des goto.

J'ai la chance, et sans doute le désavantage, d'être un très, très ancien programmeur, ayant débuté en assembleur, où l'on ne compte plus les Goto.

Sans tomber dans les excès de la programmation spaghetti, ils peuvent être utiles.

Fin de la toute petite polémique qui n'en est pas une, j'assume mes faiblesses, croyez moi.

Mais pour revenir à ma question, la raison en est un substantiel potentiel gain de temps quand mon application doit traiter des centaines de milliers de records.

Bien à vous.

Pierre

[StringBuilder]

Effectivement, au niveau machine, tout va se terminer à grand coup de JZ, JNZ, JE et JNE.

Seulement, justement parce qu'on ne fait pas d'assembleur mais de la programmation de haut niveau, il est plus lisible de programmer en utilisant les outils mis à disposition par l'outil plutôt que de tenter en utiliser d'autres.
Tu peux monter une formule 1 sur une planche à roulettes, elle va très bien avancer aussi…

Bref, tu as raison, il ne sert à rien d'entrer dans une discussion polémique sur le sujet… mais quand même !

Sinon, non, VB.NET ne permet pas de faire ce que tu cherches à faire.

En revanche, ce que tu cherches à faire ressemble s'y méprendre à un SELECT CASE, ou une série de IF, sauf si après "test1", "test2" doit toujours être exécuté, à ce moment ce sera un IF

On ne parle pas ici d'appeler des fonctions, mais bien de rester dans le même programme.

Code vb.net :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
      &label = "test1"
      pppp
      pppp
      GoTo &label
 
test1:
      xxxx
      xxxx
      xxxx
 
test2:
      yyyy
      yyyy

Peut être transcrit : (si test1 et test2 s'excluent mutuellement)

Code vb.net :

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
 
      &label = "test1"
      pppp
      pppp
select case &label
 
case "test1"
      xxxx
      xxxx
      xxxx
 
case "test2"
      yyyy
      yyyy
 
end select

Si tu dois pouvoir passer de "test1" à "test2", alors ce sera plutôt :

Code vb.net :

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
 
      &label = "test1"
      pppp
      pppp
 
if &label = "test1" or &label = "test2" then
if &label = "test1" then
      xxxx
      xxxx
      xxxx
 
end if
 
      yyyy
      yyyy
 
end if

Désolé pour l'indentation

Niveau machine, tu auras juste un "goto" supplémentaire avec le IF. Pas de quoi fouetter un chat même si tu as des milliards de lignes à gérer.
D'autant qu'avec un langage tel que VB.NET je ne serais pas surpris une seconde que le GOTO provoque une batterie de tests complémentaires au moment de la compilation (et probablement de l'exécution) afin de blinder l'utilisation de variables locales/globales puisqu'on ne sait pas vraiment à l'avance où on va tomber.

[PeD012]

D'abord merci pour ton esprit. J'apprécie.

Pour ceci

mais de la programmation de haut niveau, il est plus lisible de programmer en utilisant les outils mis à disposition par l'outil plutôt que de tenter en utiliser d'autres.

Je cherchais si VBNet admettait justement cette facilité. Je voulais donc bien ici profiter du langage et de tout ce qu'il offre

Le "Select case" ne résout en rien mon problème éventuel de performance mais que tu sembles balayer en disant

Pas de quoi fouetter un chat même si tu as des milliards de lignes à gérer.

Je n'ai pas de référence quant à la performance donc je suis plutôt rassuré par ton avis.

OK je vais adapter mon programme ( et du mieux que je peux )

Encore merci


Pierre

[StringBuilder]

Tout dépend de ce que fait ton programme.

Mais en règle générale, ce qui coûte cher, ce ne sont pas spécialement les aiguillages dans le programme, mais :
- Les IO
- La gestion mémoire

Tu parles ici de gérer un grand nombre de "Records".

J'imagine donc que ton programme va traiter des données contenues dans un fichier sur disque (latence de l'ordre de la milliseconde, qui peut vite augmenter si on ne travaille pas correctement avec un buffer pour accéder à plusieurs record par lecture/écriture).

Ensuite, qui dit Record dit aussi manipulation des données en mémoire une fois chargées : les affectations de chaînes de caractères, créations d'instances d'objets en mémoire, etc. sont de l'ordre de la dizaine / centaine de cycles CPU.

Le goto "unique" remplacer par 2 ou 3 en raison d'un select case ou des if, on reste à 1 ou 2 cycles CPU perdus : on est donc très loin en deçà.
Il ne faut pas oublier non plus que .NET optimise le code aussi bien à la compilation qu'à l'exécution. On peut donc se retrouver avec du code plus complexe de prime abord, mais plus performant au final.

A mon sens, quel que soit le besoin (mise à par si tu dois envoyer un astronaute sur Mars avec un processeur 8 bits à 3 MHz) la lisibilité du code doit toujours primer sur les "petites optimisation".
Ceci pour plusieurs raisons :
- Avoir un code lisible permet d'identifier plus facilement les incohérences algorithmiques. Ces erreurs sont en général la source de 90% des problèmes de performance (genre relire des informations sur le disque alors qu'on les a déjà en mémoire)
- Avoir un code lisible permet aussi de faire évoluer le code plus facilement. A nouveau, c'est généralement lorsqu'on met à jour le code qu'on provoque les plus grosses régression, en général car on n'a pas décelé l'impact négatif des modifications apportées

Après, il y a toujours des petites optimisations "à deux balles" qu'on peut garder sous le coude :
- Ne jamais utiliser "" mais String.Empty à la place
- Idem, toujours utiliser des constantes plutôt que des "nombres magiques"
- Toujours privilégier les opérations binaires aux opérations arythmétiques (mavar & 0x1) == 1 pour déterminer si un nombre est impair par exemple
- Ne jamais fait de concaténation de chaînes à l'aide de & mais toujours utiliser String.Concat, ou même un StringBuilder si les concaténations sont nombreuses
- Remplacer autant que possible les IF à l'intérieur de boucles par deux boucles à l'intérieur du IF/ELSE
- Etc.

Ces petites optimisations qui ne nuisent pas spécialement à la lecture (et souvent, bien au contraire) permettent d'apporter des gains significatifs lors des traitements intenses (notamment StringBuilder, les opérations binaires et surtout les IF dans les boucles).
Pour le reste, faire confiance à l'algorithme plutôt qu'à la syntaxe. De toute façon, le boulot du compilateur, c'est de réécrire ce qu'on a codé : tout ce qu'on risque de faire, c'est de passer à côté d'optimisations de ce dernier.