Bonsoir,
Je reprend ici la suite de la discussion sur les 2 dernières pages :
https://panoramic.1fr1.net/t4658p30-boite-a-outils-de-dessin#56492Bon j'ai reporté la discution ici.
Préenbule:
Pourquoi je ne suis pas d'accord sur le fait qu'on ne doit utiliser que des subs dans un programme. Déja au départ je trouve la proposition très restrictive. Pourquoi une personne peut décider pour tout le monde qu'une instruction est obsolète, alors qu'elle fait le bonheur des autres? J'ai appris à programmer sur un CBM PET 2001, puis sur un ZX81, ensuite sur ORIC1. Dans le basic d'alors, les commandes étaient restrictives. On avait GOTO et GOSUB. Sur ORIC1 est apparu repeat je crois et UNTIL ou DO LOOP, je ne sais plus. Il n'y avait pas de LABEL. Les étiquettes étaient les N° de ligne. Pour facilité la programmation, on programmait généralement de 10 en 10. Cela permettait de rajouter du code entre les lignes, la commande AUTO je crois pour renuméroter celle-ci, je l'ai eu sur le CBM, après l'ajout d'une puce, qui apportait quelques commandes en plus.
Donc pour ma part, j'ai fait mon apprentissage de la programmation en faisant du code "spaghetti", comme en disait, avec de gotos ou gosub partout. Et j'ai vraiment appris à programmer comme cela, et j'arrivais à faire des programmes intéressant qui mon bien aidés.
Puis est arrivé ATARI 560 avec un basic que j'ai acheté: le GFA-BASIC, et là il n'y avait plus de lignes, mais des étiquettes, avec une méthode procédurale. Je me suis très bien adapté, mais avec l'expérience, le schéma que l'on se fait déjà en tête était acquit.
Bien, maintenant pensons aux personnes qui arrivent maintenant, et qui testent Panoramic. Déjà au départ il se trouvent confrontées aux objets, et à leur manipulations. S'ils viennent d'un vieux basic, car pour beaucoup c'est le cas, ils se trouvent un peu perdus. C'est vrai que s'ils s'inscrivent sur le forum, mais dès que l'un d'eux poste un programme de leur cru, après les félicitations, tout de suite, et à tout les coups, on leur fait savoir, que leur programme pourrait être amélioré en employant des subs dans leur code, alors que l'assimilation n'est pas encore là. Il faut laissé au temps, le temps.
Maintenant, il y a Jack. Son but était de faire un basic simple, pour le programmeur du dimanche (ce sont ses termes). On lui a imposé des tas de choses, alors que ce n'était pas son but initial.
Bon maintenant, parlons des procédures.
C'est d'un grand confort, et à chaque fois que je peux m'en servir, je le fais. Cela permet de programmer avec des variables qui se détruisent. D'ailleurs j'ai pas envie de parler des points positifs des subs. Ceux qui interviennent ici, les connaisse, donc les utilise.
Les inconvénients: Mais il faut aussi parler des inconvénients? Et oui, si personnes n'en parle, il en existe, mais y-a-t'ont pensé. Et maintenant que je pose la question, j'ai bien l'intention de regarder mes programmes de près, car effectivement je n'y avais pas pensé avant de faire ce post. Pour dire, que j'étais très près des procédures.
Les inconvénients des SUBs.
????? Pourquoi dire qu'il y a des inconvénients? Est-ce possible?
Et oui.
Ayant eu un problème sur un programme en cours, j'ai ajouter dans les lignes de mon programme une sorte de débogage:
- Code:
-
s(number_current_line,a$,c$,v1,v2,valeur,flag)
et:
- Code:
-
sub s(n,a$,c$,v1,v2,valeur,flag)
item_add 20,str$(n)+": a$=>"+a$+"< c$=>"+c$+"< v1="+str$(v1)+" v2="+str$(v2)+" valeur="+str$(valeur)+" flag="+str$(flag)
end_sub
Cela s'est bien passé, j'ai trouvé deux erreurs: une ou j'avais
DIM_LOCAL dans une condition, et dans une autre ligne une inversions dans une fonction INSTR de TRIM et UPPER$.
Effectivement je me suis servi d'une sub, mais j'avais peu de variables. Quant serait-il si au lieu 7 variables, j'en avais 20 ou 100. Ne pas oublié que dans une sub, on se sert de variables locales, mais aussi de variables globales. Et bien une sub ne va plus.
Dans ce cas, en mettant à 50 lignes, le même appel pour tester les variables, JE DOIS RESPECTER L'ORDRE DE POSITION DES PARAMÈTRES À PASSER, et dans ce type de programme, on ne peut savoir quelles sont celles qui sont à regarder. Il faut toutes les mettre, ou il faut le faire manuellement, et c'est pas concevable. On fait appel à un débogueur, il se débrouille tout seul.
Si j'ai les lignes suivantes:
item_add 20,"item$="+item$ <--- là je passe le paramètre: item$
if numeric(item$) = 1 then nb = val(item$) <--- ici je passe: item$, nb
nb = nb+ v1 <--- ici nb, v1
Car à partir de là m'est venu l'idée de refaire un débogueur et avec une procédure, ce n'est plus possible. Si on veut contrôler tout un programme, il faut y mettre toutes les variables de celui-ci. C'est le seul moyen de faire une méthode «auto» de débogueur.
On a une instruction qui fait cela très bien: c'est «GOSUB» car cette instruction a un très grand avantage: elle embarque avec elle, toutes les variables d'un programme, même celle d'une sub.
Voici un programme qui le vérifie:
- Code:
-
' teste
label control
dim a1,a2,a3,t$ : t$=chr$(13)
hide 0
a1=100 : a2=120 :a3=130
teste()
END
==============================
sub teste()
dim_local a1,a2
a1=300
gosub control
message "retour à sub"+t$+"a1="+str$(a1)+t$+"a2="+str$(a2)+t$+"a3="+str$(a3)
terminate
end_sub
------------
control:
message "s/prg control"+t$+"a1="+str$(a1)+t$+"a2="+str$(a2)+t$+"a3="+str$(a3)
a2=500
a3=600
return
Et là ça devient facile. L'instruction gosub est un déport de la partie qui s'en sert, c'est pas seulement une instruction qui évite une répétition du même code. Si il y manque dans ce cas une variable temporaire, on la rajoute à la sub avant d'appeler GOSUB.
Ceci est un exemple très concret, pour dire que cette instruction il ne faut pas la négliger.
Mais ce n'est pas tout. Systématiquement j'emploie SUB pour coder. Mais en réfléchissant à ce texte, je me suis rendu compte que je faisais une erreur. Pourquoi?
Dans bien des cas, à partir d'une sub, j'en appelle à une autre, en mettant 2/3... paramètres.
Donc la sub appelée reçoit ceux-ci, puis les traite, Mais que faire? Il faut des variables de retour pour pouvoir récupérer celles-ci. Ensuite la sub en retour, reprend celle-ci pour mettre à jour ces variables. Donc on a:
1) passage de paramètres
2) récupération de ceux-ci
3) traitement
4) passage de paramètres soit à des variables globales, soit envoyé à une liste ou autre.
5) au retour, récupération des paramètres depuis les variables globales.
Alors qu'avec GOSUB:
1) aller au sous-programme
2) traitement
3) au retour, rien, les variables sont à jour.
Alors que diable, pourquoi faire compliqué lorsqu'on veut faire simple? C'est contre-productif!
Accueil 
Calendrier
