2ème "dim" sur variable EFFACE la variable

Je crois avoir trouvé un bug avec l'instruction dim.

Si je fais un dim avec une variable quelconque, ça marche, bien sûr.
Si je fais plus tard un deuxième dim avec cette même variable, il y a une erreur - très bien.
Si j'intercepte cette erreur avec un on_error_goto, ça débranche bien sur le label spécifié - très bien.
MAIS le contenu de la variable existante a été effacé ! Ceci est vrai pour des entiers (%) et strings ($) - je n'ai pas testé pour flottant.

Voici un petit programme qui le met en évidence:

Code:

label sub1, sub1_e, sub2, sub2_e

gosub sub1
gosub sub1
gosub sub1

gosub sub2
gosub sub2
gosub sub2

end

sub1:
on_error_goto sub1_e
dim sub1_i%
sub1_i% = 17
sub1_e:
off_error_goto
sub1_i% = sub1_i% + 1
message str$(sub1_i%)
return

sub2:
on_error_goto sub2_e
dim sub2_s$
sub2_s$ = "Début"
sub2_e:
off_error_goto
sub2_s$ = sub2_s$ + "*"
message sub2_s$
return

Bonjour Klaus,
De retour de vacances... très breves cette année... snif

Il y a une petite erreur qui s'est glissée dans ton programme. Je te donne la solution :

Code:

label sub1, sub1_e, sub2, sub2_e

gosub sub1
gosub sub1
gosub sub1

gosub sub2
gosub sub2
gosub sub2

end

sub1:
PRIVATE_ON
on_error_goto sub1_e

dim sub1_i%
sub1_i% = 17
sub1_e:
off_error_goto
sub1_i% = sub1_i% + 1
message str$(sub1_i%)
PRIVATE_OFF
return

sub2:
PRIVATE_ON
on_error_goto sub2_e
dim sub2_s$
sub2_s$ = "Début"
sub2_e:
off_error_goto
sub2_s$ = sub2_s$ + "*"
message sub2_s$
PRIVATE_OFF
return

Bien sûr tu perds le bénéfice de l'incrémentation de sub1_i%
et la concaténation de la chaine sub2_s$ mais cela a l'avantage de ne pas provoquer d'erreur...

Quand à la notion de pointeur dans un langage basic, à mon avis ce n'est pas pour tout de suite...

c'est quoi ces directives PRIVATE_ON et PRIVATE_OFF que je ne retrouve documentées nulle part, ni dans le manuel, ni dans l'annonce des nouvelles versions ?

Et apparemment elles ne sont pas reconnues par Panoramic...
Nardo, tu n'aurais pas un peu mélangé les langages par hasard ?

Non, non je n'ai pas mélangé les langages !

C'est juste un petit clin d'œil à Klaus qui désire depuis pas mal
de temps me semble t-il les fonctions PRIVATE_ON / PRIVATE_OFF
pour déclarer des variables locales...


cf le post de Klaus du 12/02/10 "Directives Private_ON et Private_OFF"

https://panoramic.1fr1.net/vos-souhaits-d-amelioration-de-panoramic-f8/directives-private_on-et-private_off-t561.htm

Pardon, ça me disait bien vaguement quelque chose, mais je n'ai pas su déceler le clin d'oeil !

Sinon, les variables locales, ça me ferait bien envie à moi aussi.

C'est clair,
quand on voit le boulot que cela à demander à Klaus pour écrire les variables pour la gestion des GLIST....
Cela devient vite innommable... mais bon, apparemment nous n'avons pas le choix....

J'en profite, pour en placer une petite, vu que je n'ai pas pu participer sur le sujet "Constante" que j'avais lancer avant de partir:
Je ne savais pas qu'en lançant ce sujet cela déclencherai des réactions si passionnées. Le sujet est apparemment très sensible... je comprend Jack qui doit se dire que l'implémentation d'une directive CONST génèrerai fatalement une moultitude de question... cf #include
Et Jack, ne cloture pas le sujet ! c'était juste une parenthèse , la question de départ concernant la gestion d'erreur sur un redim est intéressante, l'exemple de Klaus démontre qu'il y a quand même une faille (pb de calloc /free, lors de la 2eme déclaration, la variable pointe sur la nouvelle allocation de mémoire d'où 0 à l'arrivée?)

Merci, Nardo26, pour ton clin d'oeil amusé - c'est bien vu avec private_on et offd ! Effectivement, j'attends quelque chose de ce genre depuis longtemps. Mais je sais que cela pose un énorme problème à Jack: en effet, lors de l'exécution, Panoramic compile chaque ligne puis tente de l'exécuter. C'est du dynamique en temps réel. Donc, on pourrait facilement imaginer l'implémentation de private_on pour le PREMIER passage dans le sous-programme, mais que faire au moment de tomber sur le private_off ? Oublier simplement ces variables ? C'est un choix à faire au moment de la conception, mais cela risque d'interdire à un sous-programme de mémoriser des données d'un passage à l'autre - très gênant. Et que faire lors du deuxième passage dans le sous-programme, avec la commande private_on ? Redéfinir ces variables qui en principe sont censées déjà exister ?

Personnellement, je penche pour des directives au compilateur, pas à des commandes exécutées en temps réel. Des directives du type
#PRIVATE_ON / #PRIVATE_OFF
ou
#PRIVATE / #PUBLIC
Ces directives agiraient sur les commandes dim ET les commandes label et créeraient une table de symboles et une allocation de mémoire actives pour le compilateur uniquement entre ces deux directives (positionnement d'un flag ou similaire...) et prenant priorité sur les définitions globales créées ailleurs, dans le sens que la double déclaration d'une variable ou d'un label ne serait contrôlé QUE pour les symboles de cette section, et l'utilisation d'un label ou d'une variable chercherait d'abord dans les définitions "privées" (si une telle section est active) avant de chercher dans les définitions globales.

Bon, c'est ma vue personnelle des choses, sans avoir aucune connaissance de la structure interne de Panoramic, en tout cas pas plus que ce qui est dans la doc et sur le forum. Mais, c'est vrai, ça serait vraiment précieux !

L'appel à la commande "gosub" provoque déjà une action particulière.
Au moment de l'exécution du gosub, Panoramic mémorise bien l'adresse de retour pour pouvoir traiter par la suite la commande "return". (là on parle de mémorisation d'un adresse de retour pour une commande qui n'a pas encore été vu par "l'interpréteur"....)
Une question :

Qu'est-ce qui cloche dans le fait de dire : du moment qu'une adresse de retour est mémorisée, toute déclaration de variable, après le gosub, est forcement "locale" (private_on implicite) et doit être libérée lors de l'exécution du "return" (private_off)...
autrement dit, au lieu de ne mémoriser qu'une seule adresse de retour, ne peut on pas avoir également une autre adresse qui pointerai, elle, sur le premier élément d'une liste chainée de bloc de mémoire allouée suite a des "dim" locaux ?

C'est que le problème est plus complexe que cela.

Déjà, il faut traiter le cas d'un sous-programme qui en appelle un autre. Si l'on programme "proprement", il n'y a pas de goto en-dehors du sous-programme, mais je l'ai déjà vu sur le forum... Mais on pourrait maîtriser une chaîne "propre de gosub avec un système de pile qui serait dépilée par les return.

Mais cela se complique par les évènements qui peuvent intervenir n'importe quand, et en particulier pendant l'exécution d'un sous-programme normal, et même interrompre une suite de commandes dim ou label. tu imagines la complexité pour retrouver la bonne variable i% par exemple, d'autant plus qu'une routine d'évènement pourrait déclarer ses propres variables et labels et faire elle-même des gosub...

Jack a dit que cela est possible et le le crois, mais il n'a rien laissé transparaître sur une éventuelle méthode d'implémentation.

Je me doute bien de la complexité de la chose...
sinon Jack aurait déjà trouvé la solution.
D'ailleurs, c'est certainement à cause de cela que la commande goto à été bannie dans d'autres langages...

Quand à la notion de sauvegarde/restitution de contexte (gosub/return), je ne pense pas que cela soit forcement incompatible avec la gestion d'apparition d'évènements....Panoramic arrive bien à gérer sur plusieurs niveaux d'imbrication l'appel à gosub...
mais ce n'est bien sur que mon avis...

Avec mes remarques, je peux donner l'impression de vouloir donner des leçons mais ce n'est pas dans mon intention... Ne le prennez pas mal hein ?
c'est juste pour faire avancer le shmilblick et puis ça fait toujours du bien de faire travailler les neurones....

Ne t'inquiète pas, je le prends bien comme ça. Des échanges de ce genre sont très enrichissants, et c'est ainsi qu'on avance.

Une gestion de "pile" de définitions pourrait en effet résoudre le problème, à condition que le programme en Pänoramic soit écrit de façon rigoureuse.

J'avais imaginé quelque chose de plus static: à l'image de ce que le compilateur fait avec les #INCLUDE qui sont traités entièrement avant l'interprétation de la première ligne source, j'imaginais que le compilateur pourrait construire une sorte de "table" avec les numéros de ligne lors des #PRIVATE_ON et #PRIVATE_OFF, et se repérer par rapport à cette table. Mais je m'aperçois que cela ne résoud pas du tout le problème d'un sous-programme qui en appèlle un autre ayant lui-même ses# PRIVATE_XXX, car on n'aurait plus de visibilité des variables et labels privés définis au niveau supérieur. L'idée d'une pile est définitivement plus intéressante.
Ce que je voudrais obtenir, c'est ceci:

Code:

label sub1
dim i%,a$
...
i% = 1
a$ = "Principal"
...
gosub sub1
message a$+" "+str$(i%)  : ' doit afficher "Principal 1"
...
gosub sub2                        : ' doit provoquer une erreur car label non défini
...
end

sub1:
#PRIVATE_ON
dim i%
label sub2
#PRIVATE_OFF
...
i% = 2
...
message a$ + " " + str$(i%)    : ' doit afficher "Principal 2"
gosub sub2
message a$ + " " + str$(i%)    : ' doit afficher "Principal 2"
...
return

sub2:
#PRIVATE_ON
dim i%,a$
#PRIVATE_OFF
i% = 3
a$ = "Sub2"
message a$ + " " + str$(i%)    : " doit afficher "Sub2 3"
...
return

Tu vas beaucoup plus loin que ce que je pensais.
Dans ton exemple, tu parles de procédures locales (cf sub2).
Pour réaliser un truc pareil, il faudrait avoir une syntaxe un peu plus structurée, non pas des définitions de label, mais de véritables définitions de début et de fin de procédure (genre begin/end) pour bien délimiter des blocs de code. -> dans ce cas, il faut exclure la cde Goto et je pense que beaucoup de personnes se mettraient à hurler !

le problème de l'utilisation d'une directive de compilo c'est que juste après le #PRIVATE_OFF, ta variable i% normalement devrait repointer sur la variable globale déclarée en début de prog. sinon comment fait-il pour savoir de quel i% on parle ?
Des directives #PRIVATE_XXX devraient "encapsuler" (ce n'est pas vraiment le bon terme mais je ne vois pas comment désigner la chose) les variables locales. Dans ce cas, il n'y a plus d'ambiguïté.

Depuis quelques jours je ne suis plus chez moi, et j'arrive seulement à me connecter.
Pour ce qui est des gotos, vu que c'est moi qui ais posé le problème, je me sers de cette instruction parce qu'elle existe, qu'elle est plus simple dans certain cas et ne pose pas de problème pour l'instant.
A partir du moment que celà créé une difficulté pour améliorer, apporter d'autres possibilités, en quoi cela m'oblige à crier au scandale?.

Je fais seulement avec les moyens mise à la disposition. Je ne comprend seulement pas pourquoi il faut décrier une instruction sans en donner la raison vu qu'elle a étée construite. Il n'y a pas de fixation pour ou contre. Elle est disponible et parfois je l'utilise, et si vous regardez l'ensemble de mes codes, je crois qu'on en trouve très peu. La seule chose est que ne trouve pas normal qu'on critique l'utilisation d'une instruction qui jusqu'à lors ne posait pas de problème, juste pour la forme Si la raison est donnée, à partir de là, ça me dérange pas plus que ça!

Je me demandais, mais j'ai pas bien réfléchi encore, si on ne pourrait pas avoir des variables communes comme a%... et sauvegardées dans des tableaux. Chaque procédure aurait un numéro par exemple et j'en reste là, vu que vous allez me prouver que c'est pas une bonne idée.
@+

Nul n'est mon intention de décrier la cde Goto,
car un langage Basic sans commande Goto, ce n'est plus un basic.
J'ai bien préciser que cette cde avait été bannie dans d'AUTRES langage...

Moi-même il m'arrive de l'utiliser parfois car cela simplifie énormément certains tests imbriqués....

Mais je me répète, dans le contexte de déclaration de variables locales, la fonction Goto peut poser problème suivant la manière dont on l'utilise. Comme le dis Klaus, tant que Goto est utilisé pour aller un peu plus loin localement dans une procédure, cela n'est pas dérangeant.

Dans le cas d'un programme où le traitement se déroule de manière linéaire, il n'y a aucune raison de ne pas utiliser cette commande. Du moment qu'il y a des gosub, là je dis qu'il faut faire attention à son utilisation.

Imagine le cas où par exemple dans une procédure dans une boucle [for i%- next i%] tu fais un goto pour aller dans une autre boucle [for i%-next i%] qui se trouverai dans une autre procédure... et que les variables i% sont des variables locales...
L'exemple est un peu gros, mais peut s'envisager du moment que nous ne sommes pas tous des pros de la programmation...
Quand aux personnes qui se mettraient à hurler si Goto venait à disparaitre, crois moi, je pense que dans certains cas j'en ferai parti !
Puis de toute manière, ce n'est qu'une discussion, ce n'est pas à nous d'en décider, c'est à Jack car après tout c'est son bébé.

Pour moi goto peut disparaitre, cela ne m'empèchera pas de programmer.
Je dirais que mettre un goto pour sortir sur un autre gosub ne me gène pas, vu que le basic le permet et qu'il est dépilé. J'ai pendant plusieurs année programmé en gfa basic, ou cela n'aurait pas été permit.
Je crois qu'on est tous responsable, et là mettre un goto pour sortir d'une boucle for/next, là je crirais plus volontier au sacrilège.
La seule chose nécessaire est la notice qui dit ce qui se doit et se qui ne se doit pas. A partir de là on respecte la volonté et les intentions du concepteur, qui même si le logiciel n'est pas fini, pourra continuer à faire les directives comme il lui convient.
Ce qu'il faudrait savoir, c'est dès maintenant ce qui le gène ou pas. Pour ma part je ne pense pas qu'il soit nécessaire de revoir les vieux programmes, ils resteront compilés dans l'éditeur du moment, et pour les autres, il n'y aura pas beaucoup de goto à reprendre.

Pour ma part je ne toucherai pas à la commande Goto. Elle est très bien comme elle est. Remettre en question sa présence serait une hérésie. J'avais seulement émis l'idée de sa suppression dans le cadre d'un "blindage" en ce qui concerne les aléas possibles avec des variables locales.

La supprimer voudrait dire la perte de compatibilité avec une grande partie des programmes écrits actuellement. Et je suppose que la réécriture de vieux programmes pour une histoire de goto, cela ne doit pas enchanter grand monde (à moins d'être maso).

Pour en revenir au sujet, il n'y a pas de mauvaises idées. Chacun apporte son avis et si modestement cela peut en amener d'autres tant mieux !!
non ? un forum c'est fait pour s'échanger des idées.

On pourrai comme tu le signales, utiliser des tableaux de variables globales qu'on indicerai à partir d'un numéro de procédure. Je pense que cela marcherait mais... aie ! (pas dans les dents cosmos, pas dans les dents! )

- cela rajouterai de nouveaux n° d'identification (déjà que pour les objets je trouve ça dommage de ne pas avoir une étiquette). Puis on a vite fait de se planter dans un indice...

- cela impose des noms de variables pour des procédures, je trouve plus parlant un truc du genre indiceFiche% que z%(n°proc). A la rigueur quand il s'agit d'indice de boucle genre i%,j%,k% (merci Fortran!) pourquoi pas... mais pour le reste ?

Je crois que Jack avais déjà fait une tentative de déclaration genre SUB_LABEL ou d'autres trucs dans ce genre pour essayer, je suppose, la création de variables locales... mais je n'arrive pas à le retrouver dans le forum...

Je ne pense pas que un goto dans la même procédure gène grand monde. Je l'ai employé en toute conscience entre 2 procédure parce que ça marche. Point final pour cela. Mais si il faut n'autoriser un goto qu'à l'intérieur d'une procédure, ça ne me dérange pas. Des vieux programmes personnellement j'en ai pas de trop, et très peu à inclure aujourd'hui. Panoramic a été un aprentissage avec les nouvelles fonctions qui se rajoutaient. Il y a moi, et les autres.
Pour les variables en tableaux l'idée m'est venu en écrivant, et je pensais à cela:
On définit un tableau qui sert à stoquer les variables 'disons locales' (ce qui est faux évidemment) à la sortie d'une procédure avec le principe: procédure 1, donc N°1, procédure 2, donc N°2.
On récupère si nécessaire les variables en revenant dans la procédure, donc l'idée que j'avais eu un instant:
dim stock%(10,10) , stock$(10,10) ...
procédure 1
......
......
stock%(1,1)=a%:stock%(2,1)=b% ...... etc...
return
procédure 2 (évidemment c'est ici un label)
a%=stock%(1,2)... (on récupère si c'est nécessaire)
......
stock%(1,2)=a% etc......
return

On peut même faire une variable qui sert de n° à la procédure, ainsi:
procédure 1
variable%=1:gosub récupération
' traitement du sous/prg
gosub sauvegarde
return

récupération:
a%=stock%(1,variable%): etc...
return
sauvegarde:
stock%(1,variable%)=a% etc...
return

C'est une idée qui m'es venu un instant, on en fait ce qu'on en veut.

Le système de tableaux de variables permet seulement de "grouper" des variables GLOBALES en fct de leur utilisation dans les procédures. Cela charge dès le départ la RAM avec toutes les variables nécessaire au programme... l'avantage d'une véritable variable locale, reste l'allocation dynamique de la mémoire ou l'utilisation de la pile (le tps d'exécution de la proc) puis de sa libération. En gros, cela permet d'utiliser ponctuellement de la RAM en fct des besoins.

Néanmoins, ton idée de tableaux met un autre truc en évidence :
les variables locales statiques... mais là je m'emporte un peu il faut que cela reste du basic (le but n'étant surtout pas de se rapprocher du C)

L'idée des variables locales, je suis pour à 100 pour 100.
Je n'en parle pas, parce que le sujet a été mainte fois évoqué par d'autre, et je ne veux pas encombré.

Par contre l'idée du tableau que j'ai évoqué, c'est à l'essais qu'ont peut juger. Mais je trouve que c'est un bon dépannage. Les variables choisis, on les considère comme locale, ce qui de toute évidence est faux, mais bon, ça évite de mettre des noms à rallonge pour bien montrer l'apartenance à une méthode ou une procédure. On emploi des variables simples, qui ne seront modifié (je veux dire qui seront restituées) au retour.

Moi je lance une idée de secours. Personne n'est obliger d'y croire. Personnellement tant que je n'auai l'essai de ce type de programmation, je ne ferais pas de pub pour cela.
Il y a forcément une perte de temps pour sauvegarder et rétablir à chaque procédure les variables incriminées, mais est-ce mesurable?
Par contre je pense que si on procède ainsi, il sera bon de faire un tableau au départ pour savoir à quoi ça sert, du genre:
sim stock%(10,10):' stock%( nom,procédure)
' pour:
' 1:essai
' 2:calcul
Je pense que vous comprenez ce que je veux dire.

Citation :

Hier, c'était l'histoire, demain: un mystère, aujourd'hui est un cadeau, c'est pourquoi c'est le présent

à+

Il m'est arrivé un drole de truc tout à l'heure, lorsque j'ai édité de suite le poste que j'avais envoyé, je me suis retrouvé dans le poste de nado26. J'ai pas pensé, j'airai du mettre une énormité pour voir la réaction!

Désolé pour cette réponse tardive, j'ai eu, comme qui dirait, une interruption prioritaire ....

Concernant l'histoire de l'edit du post, j'aurai démarré comme un mirage F1 équipé de fusées Jato !

C'est sur que l'utilisation des tableaux permet d'avoir une notion de sauvegarde/restitution de contexte qui, je pense, peut être utile dans certain cas lors d'une mise au point d'une procédure (ou même d'un groupe dans le cas d'un include, genre Glist par ex.) en version béta.

Franchement ton idée est loin d'être bête car en creusant un peu, on pourrait même s'appuyer de l'utilisation des tableaux pour créer une sorte de fenêtre de débugger (en // genre Real-watch) qui permettrait de visualiser les différentes variables d'un module/prog (avec déclenchement d'une mise à jour sur un évènement de type TIMER)...

Puis une fois la mise au point terminée rien n'empêche de faire un search&Replace des variables de type tableaux par des noms de variable plus explicite...

Je ne sais pas si je me suis clairement exprimé....

Ca bug un peu ce soir dans le forum...
Mon message ci-dessus a été dupliqué car le site m'a signalé qu'entre-temps un nouveau message avait été écrit, ce qui n'est pas le cas...
d'ou l'edit du 2eme post pour signaler ce bug...