[R] DIM_LOCAL et sous-programme

Bonjour les Panoramiciens.

J'aimerai avoir votre avis.
Celà fait un bon moment que je suis ce forum, et donc j'ai mes petites habitudes, et je me sors bien de Panoramic.

Je viens de publier un programme, dont personnellement je ne pensais même pas avoir le moindre retour, car les seuls que je vois sont sont qui concernent les jeux et les dessins.

C'est vraiment pas le problème, mais avec ce programme, je viens de constater une choses, et sans avoir à faire de commentaires, je préfère mettre un programme teste pour voir par vous-même:

Code:

' teste avec SUB et S/P
dim procedure$ : label essai
teste()
end
' ---------
sub teste()
   dim_local procedure$ , teste$ : procedure$ = "teste()"
   teste$ =" on est dans teste()"
   gosub essai
   message procedure$ :' ici c'est foutu pour la variable locale
end_sub
' ---------
essai:
   ' normalement le s/p est une extension de ce qui l'appel
   procedure$ = "essai:"
   message "teste$="+teste$ :' donc ici on récupère la variable locale
return

Je sais que pour certains, on ne met pas le même nom de variable déjà définie comme global, mais normalement, il n'y a pas de rapport.
Je me suis déjà à rechercher avec GFA BASIC des erreurs car je ne m'y retrouvais pas, jusqu'à ce que je m'aperçoive qu'une variable était resté locale, et que je ne m'étais pas rendu compte de ceci.

Ici cela semble fonctionner autrement! Qu'en pensez-vous? Est-ce un bug? Personnellement  je pense que oui, mais un langage appartient à son auteur, et peut-être a-t'il un autre avis.

Bonjour Oscaribout,

tu as dit:

Citation :

Je sais que pour certains, on ne met pas le même nom de variable déjà définie comme global, mais normalement, il n'y a pas de rapport.

C'est exact, mais évites de le faire puisque tu as une variable globale inutile de la déclarer en local.

Mais ton problème est ailleurs.

Il s'agit de l'ordre d'exécution des lignes du code, essai ceci:

Code:

' teste avec SUB et S/P
dim procedure$ : label essai

teste()
end
' ---------
sub teste()
   dim_local teste$
   teste$ ="XXX"
   gosub essai
   procedure$ = "retour du sous-prog essai, teste$="+teste$
   message procedure$
end_sub
' ---------
essai:
   message "teste$="+teste$ :' donc ici on récupère la variable locale
return

A+

Avec Panoramic :

dim a$ => a$

dim_local a$ => masub_a$

- une variable locale est libérée à la sortie de la procédure dans laquelle elle est déclarée.
- une variable locale peut même si ce n' est pas recommandée porter le même nom qu' une variable globale
elle est interprété avec le nom de sa procédure en préfixe ( un truc dans le genre ).

Normalement, si tu déclares une variable locale masub_a$ ( masub étant le nom de la procédure) tu devrais
avoir un message d' erreur.

@Ygeronimi,
Tout ce que tu dis est vrai, mais dans le cas d' Oscaribout, la variable locale n'est pas perdue car on fait appel à un sous-programme interne à la SUB.

Le problème est l'ordre d'exécution des lignes dans la sub.

A+

Oui, merci pour ce partage.
Ygeronimi, je ne fais pas appel de la sub à une autre sub, mais à un sous-programme.

Normalement l'appel à un sous-programme, revient à cela:
sub teste()
  dim_local teste$
  teste$ ="XXX"
  ' gosub essai

  ' ligne du sous-programme
  procedure$ = "essai:"
  message "teste$="+teste$ :' donc ici on récupère la variable locale
  ' retour du sous-programme

  message procedure$
end_sub

Normalement avec gosub, on fait une extension, sans rien perdre.

Mais il me semble qu'avec certain langage, on a ce qu'on appel un effet de bord, si je me souviens bien.

Si je m'en réfère à la lecture de ce qu'avait dit Jack, la réponse tient à ce que je dis. Peut-être ai-je mal lu ou mal compris.

Pour moi, je rejoins ce que dit Jean Claude.
@+

Les essais sont faits avec la version 0.9.27i8. Je n'ai pas la dernière version.

En regardant de près le programme que j'ai fait à partir des résultats que j'avais obtenus, je constate une erreur.

Il est tout à fait normal d'avoir un retour pour procedure$ avec "essai", vu que j'ai modifié la variable dans le sous-programme "essai". J'ai fait un mauvais rapport, et pour l'instant tel qu'il est mon poste ne vaut rien. Je vous prie de m'excuser.

Je vais continuer mes recherches pour voir où ça foire!

Il me semble qu’il y a bien de confusions entre variable globale et variable locale, entre SUB et GOSUB , entre la durée de vie d’une variable et sa visibilité, etc.
Le résultat du 1er code de Oscaribout est tout à fait correct et tel quel il n’y a aucun bug.

J’écrirai une petite explication sur tout ça tout à l’heure, car maintenant on m’appelle pour d’autres affaires.
A +

Papydall a écrit:

Il me semble qu’il y a bien de confusions entre variable globale et variable locale, entre SUB et GOSUB , entre la durée de vie d’une variable et sa visibilité, etc.

Je n'ai pas de problème de compréhension entre ces mots. J'ai seulement pas fait un programme qui est le reflet de ce que j'ai constaté. Et lors de l'écriture du code que j'ai mis, restait l'arrière pensé de mon programme, j'ai vraiment fait une confusion.

Maintenant il faut que je relise tout l'ensemble pour voir mon erreur. Selon les constatations, je ferais ou non un rapport. pour l'instant je déclare qu'il n'y a pas de problème, seulement celui d'un spacio-temporel entre le clavier et la chaise, moi assit sur un nuage. Je signale que je ne fume rien, encore moins la moquette, sans aucun médicament délirant. Cela fait 60 ans que je me soigne par l'homéopathie, même pour les cas graves. Mais peut-être ai-je un petit vélo!
De toute façon je n'en saurais pas plus avant ce soir.



ré-edit: erreur sur le nom de Papydall

Dernier rapport:

Il n'y a pas de problème avec le retour des variables locales reçues par GOSUB.

Avec ma boite, j'avais remarqué une différence entre les N° de ligne relevés avec NUMBER_CURRENT_LINE, et le nom de la procédure ou du sous-programme qui étaient relevé à chaque appel de la boite.

Ors le nom de la procédure n'était pas celui que je pensais relevé, mais celui d'un caption que je mettais en évidence dans mon programme pour la mise au point. Mais ce dernier n'était pas systématiquement mis à jour, pour des parties de code que j'estimais pas nécessaire de relever.

Donc une précipitation de ma part pour voir un bug, là où il n'y en avait pas.

Ceci est un post dans bavardage, mais je vais mettre résolu!

On peut toujours utiliser dans un programme et ses sous-programmes des variables globales et des variables locales ayant le même identificateur.
L’idée d’éviter d’utiliser le même identificateur pour une variable globale et une variable locale est FAUSSE.
Un programme peut être écrit par plusieurs codeurs ; chacun se charge d’un sous-programme (ou plus).
Ces différents codeurs n’ont absolument pas besoin de savoir quelles variables globales sont utilisées dans le programme principal.

Une variable globale (déclarée par DIM) est visible partout, dans le programme principal et ses sous-programmes si et seulement si le sous-programme ne déclare pas lui-même une variable locale du même nom par DIM_LOCAL.
Sa durée de vie est celle du programme principal.
Par contre une variable locale déclarée dans un sous-programme par DIM_LOCAL n’est visible que dans ce sous-programme et elle est PRIORITAIRE sur la variable globale.
En dehors de son propre sous-programme elle n’existe plus.
Sa durée de vie est donc celle du sous-programme.

Panoramic permet d’utiliser deux sortes de sous-programmes :  SUB / END_SUB et  GOSUB / RETURN.

Appel d’un sous-programme SUB / END_SUB.

Lorsque le programme principal (ou un sous-programme) appelle un sous-programme défini entre SUB / END_SUB, le système procède comme suit.
Le système commence tout d’abord par sauvegarder l’environnement du travail de l’appelant en mettant sur la pile (PUSH) les contenus des différents registres principaux (l’accumulateur, le compteur ordinal, le registre d’état, le pointeur de pile, etc).
Puis il dépose sur la pile une copie des variables locales sur lesquelles va travailler le sous-programme.
Si des variables globales portant les mêmes noms que des variables locales existent, elles seront purement et simplement ignorées par le sous-programme : la priorité est aux variables locales.
Arrivé à END_SUB, le système élimine la copie des variables locales (leur durée de vie s’achève ici), récupère de la pile (POP) l’ancien environnement de l’appelant en rétablissant les valeurs des registres initialement sauvegardés et continue l’exécution du programme à l’instruction qui vient juste après l’appel.

Appel d’un sous-programme par GOSUB
Ici le système sauvegarde sur la pile seulement la valeur du compteur ordinal  qui indique l’adresse de la prochaine instruction qui suit le GOSUB.
Le système se débranche de l’appelant pour se brancher sur le sous-programme.
Toutes les variables globales dont la visibilité n’est pas éclipsée par les variables locales  sont reconnues ainsi que toutes les variables locales  de la SUB qui a fait l’appel.
Arrivé à RETURN, le système récupère l’adresse de retour à partir de la pile et continue son exécution et la charge dans le compteur ordinal.

Commentons le code de Oscaribout

Code:

' teste avec SUB et S/P
dim procedure$ : label essai
teste()
message procedure$
end
' ---------
sub teste()
   dim_local procedure$ , teste$ : procedure$ = "teste()"
   teste$ =" on est dans teste()"
   gosub essai
   message procedure$ :' ici c'est foutu pour la variable locale
end_sub
' ---------
essai:
   ' normalement le s/p est une extension de ce qui l'appel
   procedure$ = "essai:"
   message "teste$="+teste$ :' donc ici on récupère la variable locale
return

La ligne 2 déclare une variable globale procedure$.
A ce stade, la variable existe et comme aucune valeur ne lui est affectée, le système lui donne par défaut la chaîne vide.
La ligne 3 appelle le sous-programmes teste().
Le système sauvegarde l’environnement de travail du programme principal et se branche sur le sous-programme.
Ce dernier déclare lui aussi une variable locale procedure$ de même nom que la variable globale et lui affecte la valeur  "teste()"
La variable globale procedure$ existe toujours mais elle est éclipsée par la variable locale de même nom, de sorte que le système ne « voit » que    la variable locale.
La ligne 9 fait un appel au sous-programme essai par l’instruction GOSUB.
Remarquez que nous sommes encore dans la SUB.
Le système mémorise l’adresse de l’instruction suivante (message essai) et se branche à essai
Ce sous-programme modifie le contenu de la variable procedure$ qui contient maintenant la valeur  "essai:"
Mais de quelle variable procedure$ parle-t-on ? de la globale ou de la locale ?
Comme le sous-programme essai : fait partie de la SUB teste() et qu’on est à l’intérieur de la SUB, c’est la variable locale qui est visée.
La variable teste$ aussi reste visible.
L’affichage par message est tout à fait correct et c’est à ce quoi on s’attendait.
Arrivé à l’instruction return, le système va chercher sur la pile la valeur du compteur ordinal précédemment sauvegardé, c’est ce qu’on appelle l’adresse de retour, et continue son déroulement.

Sur la ligne 10, Oscaribout a commenté   ' ici c'est foutu pour la variable locale
Non, ce n’est pas foutu : le sous-programme essai : a bien fonctionné et comme on lui a indiqué de modifier la valeur de la variable procedure$ il a obéi comme il se doit.

Pour moi, c’est correct.
Le contraire m’aurait surpris.

NB : dans cet exemple, la variable procedure$ déclarée comme globale, n’a jamais été utilisée ni modifiée, elle vaut toujours la chaîne vide.
Pour vous en convaincre, affichez-la par message procedure$ juste avant le END du programme principal.

Il faut retenir qu’une variable déclarée globale existera tant que le programme principal reste en cours.
Sa visibilité peut être éclipsée par une variable locale de même nom, mais non modifiée par celle-ci.
L’existence et la visibilité d’une variable locale durent le temps de l’exécution de la SUB où elle se trouve. En dehors, elle est supprimée par le système, contrairement à une variable globale qui existe tant que le programme n’est pas terminé soit par TERMINATE soit par la fermeture par la croix ou encore si le programme ne contient pas une instruction de libération de la dite variable par FREE.

EDIT
On s’est croisé Oscaribout.
De toutes les façons cette discussion nous a permis d’échanger nos points de vue.
A+

Wahou, ca c' est un post à mettre en mémoire.

Belle démonstration,

Je valide tout ce qui est dit sauf:

Code:

L’idée d’éviter d’utiliser le même identificateur pour une variable globale et une variable locale est FAUSSE.

Là je ne suis pas d'accord:
1) Ce n'est pas une idée mais un conseil que j'ai donné plus haut.
2) dans le cas du code de Oscaribout, la variable locale procedure$ (j'ai bien dit locale) n'est pas utile vu qu'on peut faire le retour en utilisant la variable globale du même nom. (Voire le code que j'ai posté)
3) je pense, en l’occurrence, que c'est justement le fait d'avoir déclaré cette variable à la fois globale et local qui complique la compréhension du code.

Pour finir un conseil ne tiens pas lieu de règle impérative, mais il peut être utile au débutants. Les programmeurs expérimentés peuvent se passer de ce conseil, mais (pour moi) les débutants feraient bien de s'y tenir.
Je ne connais pas l'expertise de Oscaribout en programmation Panoramic: peut-être que pour lui ce conseil n'est pas valable.  

Pour le reste, comme je l'ai dit, tout ce que tu dis Papydall est parfaitement vrai.

A+

Je suis d'accord avec Jean-Claude. Mieux vaut éviter tout ce qui peut être ambigu et même si c'est possible, éviter d'utiliser les mêmes noms ne peut qu'améliorer la lisibilité du code

Jean Claude a écrit:

Je ne connais pas l'expertise de Oscaribout en programmation Panoramic: peut-être que pour lui ce conseil n'est pas valable.

Il n'y a pas de problème de ce côté là, je maitrise bien Panoramic, et je connais le rapport entre les sub, gosub et s/p.
Le problème est que je devais être encore endormi ce matin quand j'ai fait cette constatation. J'ai tout vu à l'envers, et j'ai eu du mal à penser autrement, certain qu'il y avait un problème.

Normalement je me débrouille seul, mais j'ai eu besoin de m'inscrire pour pouvoir lire les mots de passe sur certain sites. J'aime pas demander de l'aide en pensant que je suis assez malin pour me débrouiller tout seul. Preuve que ça ne marche pas à tous les coups. Minable que j'ai été sur ce coup là.

A propos j'ai vu ton site Papydall, pas mal!
La question que je me pose, est-ce que tu en as un en arabe

J'ai vu aussi d'autre sites de Panoramicien. Il y en a certain qui sont balèze! Je ne sais plus si c'est celui de Mike, avec les antennes radio! Chapeau.

Heureusement que tu as eu un problème alors sinon tu nous aurais privé de faire ta connaissance. Ca aurait été bien dommage

Oscaribout a écrit:

Normalement je me débrouille seul, mais j'ai eu besoin de m'inscrire pour pouvoir lire les mots de passe sur certain sites. J'aime pas demander de l'aide en pensant que je suis assez malin pour me débrouiller tout seul

Soit ! Mais il n’y a aucun mal à demander de l’aide si on bloque sur quelque chose.
On le fait tous et on apprend les uns des autres.
Une de mes devise est : le savoir ne vaut rien s’il n’est pas partagé.
Tes interventions sont toujours les bienvenues.
Tu as certainement remarqué que nous sommes une communauté plutôt sympathique où règne la joie et l’humour.

Oscaribout a écrit:

A propos j'ai vu ton site Papydall, pas mal!  
La question que je me pose, est-ce que tu en as un en arabe  

Non, je n’en ai pas.
C’est le seul et je l’ai crée dans le  but de sauvegarder certains de mes codes.
J’avais une bonne collection de programmes sur mon ancien Webdav et je ne peux plus y accéder.
On m’a dit que j’ai dépassé la limite de 200 MB et que mon webdav est bloqué.
Les responsables n’ont même pas répondu au courrier que j’ai leur envoyé.
Comme tout est perdu, j’ai créé mon site pour me servir de lieu de sauvegarde et aussi  pour tester si j’y arriverais.
Il s’est avéré que créer un forum est à la portée de tout le monde.

Au plaisir de te lire.

Au moins, Oscaribout, tu nous as permis de débattre.

Comme quoi, intervenir sur le forum c'est utile.

A+