La gestion des variables dans SUB

Je ne comprends pas la gestion des variables dans SUB.

Y at-il aucun moyen d'envoyer des variables à un SUB et utiliser le résultat en dehors de la SUB?

Code:

dim i,x
for i = 1 to 3
  routine(i)
  message "Out "+str$(x)
next i
end

sub routine(x)
  message "In "+str$(x)
end_sub

Si cela fonctionne correctement (pas un bug), quel est le point de dimensionnement d'une variable locale à l'intérieur? Dans ce qui précède, x est déjà local.

D'ailleurs, quand j'utilise dim_local, ça ne marche pas. ("Name already defined"). Version 0.9.25i4.

Code:

dim i
for i = 1 to 3
  routine(i)
  message "Out "+str$(x)
next i
end

sub routine(x)
  dim_local x
  message "In "+str$(x)
end_sub

Merci bien, Treehouse.

Bonjour treehouse,
Quand on écrit Sub routine(x), x devient une variable locale de la sub, indépendante de la variable globale x.
On peut redéfinir une variable globale x en variable locale x dans une sub, sans modifier la variable globale.
Ainsi on peut écrire:

Code:

DIM x
x = 5
Mysub(x)
PRINT "x= " + STR$(x): ' -> x=5, variable globale non modifiée par la sub
END

SUB Mysub(z)
DIM_LOCAL x
x = 12: ' x variable locale, ne modifie pas la variable globale x
END_SUB

Pour ton premier exemple, tu peux écrire:

Code:

dim i,x
for i = 1 to 3
     routine(i)
     print "Out "+str$(x)
next i
end

sub routine(z)
     x = z: ' x variable globale, z variable locale
end_sub

Hello treehouse

Code:

SUB Routine(X)
…
END_SUB

X est un paramètre formel et joue le rôle de variable locale de sorte que tu ne peux pas faire DIM_LOCAL X à l’intérieur de la SUB , car ça sera considéré comme une double déclaration.

Voilà comment  

Code:

dim i
for i = 1 to 3
 routine(i)
 message "Out "+str$(i)
next i
end

sub routine(x)
 message "In "+str$(x)
end_sub

Pour des plus amples informations, regarde ICI

Hello papydall !

Je commence à devenir vieux : Il y a toujours quelqu'un plus rapide que moi  
Coucou JL35

Il y a une technique que j'utilise souvent, dans KGF_SUB.bas, mais aussi séparément, dans mes procédures personnelles. A l'intérieur de la procédure, je définie une variable globale, mais réservée uniquement à cette procédure. Pour cela, je lui donne le nom exact de la procédure, suivi évetuellement de $ ou % ou _ avec une extension de nom. Et ainsi, je peux retourner des valeurs sans problème.

Voici un exemple:

Code:

cube(3)
message "3 puissance 3 = "+str$(cube%) : ' affiche 27
cube(5)
message "5 puissance 3 = "+str$(cube%) : affiche 125
end

sub cube(in%)
  if variable("cube")=0 then dim cube%
  cube% = in% * in% * in%
end_sub

Rien n'empêche de définir 2 variables, 3 ou plus...

Bien sûr, cela ne remplace pas le retour d'une valeur via la variable passée en paramètre. Mais à ce jour, Panoramic ne connait que le passage "by value". Cela veut dire qu'avant l'appel de la procédure (tout comme d'ailleurs pour tout appel de fonction interne de Panoramic ou pour CALL_DLL), chaque paramètre est "évalué" car il peut être une expres​sion(dans mon exemple ci-dessus, j'aurais pu faire cube(2+3) ce qui est identique à cube(5) ). Et c'est le résultat de cette évaluation, placé dans une mémoire temporaire, qui sera passé à la procédure. Ceci explique pourquoi tu ne peux pas retourner une valeur à travers un paramètre formel de la procédure: tu ne changes que le contenu de l'emplacement temporaire, pas le contenu de la variable d'origine !

Donc, tous les paramètres en Panoramic sont "by value" et jamais "by reference".

Ah oui, je comprends. Merci JL35, papydall et Klaus.

Klaus, votre code est une astuce. Il fonctionne comme une variable de retour général. En fait, vous avez créé un palliatif au manque d'une fonction! Chaque fois que le code principal utilise le SUB, il peut accéder à la variable globale ("cube"), puis le libérer.

Code:

cube(3)
message "3 puissance 3 = "+str$(cube%) : if variable("cube")=0 then free cube%
cube(5)
message "5 puissance 3 = "+str$(cube%) : free cube%
cube(7)
message "7 puissance 3 = "+str$(cube%) : free cube%
end

sub cube(in%)
  if variable("cube")=0 then dim cube%
  cube% = in% * in% * in%
end_sub

Curieusement, dans ce qui suit, la ligne

Code:

if variable("cube")=0 then free cube%

devrait logiquement être

Code:

if variable("cube")=1 then free cube%

, ce qui semble être un bug, mais

Code:

free cube%

fonctionne très bien. Cette méthode pourrait revenir un certain nombre de variables. Excellent!

C'est parce que la ligne

Code:

if variable("cube")=0 then free cube%

ne contient pas le %. Il faut coder comme ceci:

Code:

if variable("cube%")=0 then free cube%

Oui, je n'ai pas entendu. Merci. Mais maintenant je suis confus au sujet de variable() et votre utilisation de celui-ci sans "%". D'ailleurs, votre code plus tôt (pour moi) a une erreur sur DIM.

J'obtiens l'erreur avec DIM cube (réel). Celles-ci doivent "free cube" ou "free cube%", mais pas avec $. ...

J'ai trouvé une méthode encore plus facile. Un sous-programme peut retourner une variable de chaîne. Je me demande si cela peut causer des problèmes de mémoire si utilisé à plusieurs reprises, mais je vais essayer.

Code:

dim cube$,n
for n=1 to 3
cube(n)
message str$(n)+" puissance 3 = "+cube$
next n
end

sub cube(in)
  cube$=str$(in*in*in)
end_sub

Pour coder une SUB qui retourne un résultat à l’appelant (un peu comme une fonction), on peut utiliser une variable de retour (en tant que variable globale) qui porte le même nom que l’identificateur de la SUB.

Si on désire utiliser le résultat de la SUB dans un calcul, on le fait à travers  la variable de retour.
Il n’est plus nécessaire de tester l’existence ou non d’une variable pour la déclarer par DIM dans la SUB.
Et puis je n’ai jamais éprouvé le besoin d’éliminer une variable par FREE.
A quoi cela peut-il servir ?
A mon avis la commande FREE était jadis utile, à l’époque où on ne disposait que de quelques ko de RAM.
Le ZX81 ne disposait que d’un seul et unique k0 à l’époque. Une extension de 16 Ko n’a vu le jour que plus tard.

Voici comment je code une SUB dont j’utilise son retour dans un calcul.

Code:

DIM atn2
atn2(-1,0.5)
message sin(atn2)
end
rem ============================================================================
' ATN2 : calcul l'ArcTangente(y/x) en tenant compte des signes de X et de Y.
' Le résultat (en radians) appartient à l'un des 4 quadrants.
SUB ATN2(x,y)
    dim_local pi
    pi = acos(-1)
    If x = 0
       atn2 = Sgn(y) * pi/2
    Else
     If x > 0
        atn2 = Atn(y / x)
     Else
        if x < 0 and y = 0
           atn2 = atn(y / x) - sgn(x) * pi
        else
           atn2 = Atn(y / x) + Sgn(y) * pi
        end_if
     End_if
  end_if
END_SUB
rem ====================================================================

La méthode de Klaus est tout aussi bonne et on peut en inventer plusieurs ; on n’en a que l’embarras du choix.

Exact, Treehouse. Voici mon code corrigé:

Code:

cube(3)
message "3 puissance 3 = "+str$(cube%) : ' affiche 27
cube(5)
message "5 puissance 3 = "+str$(cube%) : affiche 125
end

sub cube(in%)
  if variable("cube%")=0 then dim cube%
  cube% = in% * in% * in%
end_sub

Désolé...

Papydall, votre méthode est encore plus net. Et Pan'c est bizarre - je veux dire, intéressant!

Saviez-vous aussi que les sous-programmes peuvent prendre $ ou% comme leur nom? Voici un exemple:

Code:

dim cube%,n,add$,p$,q$
memo 1

full_space 1
for n=1 to 5 step 0.5
   cube%(n)
   item_add 1,str$(n)+"^3 = "+str$(cube%)+"    real: "+str$(n*n*n)
next n

for n=65 to 80
   p$=str$(n):q$=chr$(n)
   add$(p$,q$)
   item_add 1,add$
next n
end

sub cube%(in)
   cube%=in*in*in
end_sub

sub add$(a$,b$)
   add$=a$+" = "+b$
end_sub

papydall a écrit:

La méthode de Klaus est tout aussi bonne et on peut en inventer plusieurs ; on n’en a que l’embarras du choix.

Oui, mais une méthode peut présenter des avantages dans certaines circonstances. Dans mon projet actuel, il sera plus utile d'envoyer trois variables à un "pseudo-fonction" et récupérer tous les trois après, je vais probablement utiliser mon str$(résultat) méthode.

Citation :

Il n’est plus nécessaire de tester l’existence ou non d’une variable pour la déclarer par DIM dans la SUB.

Klaus a introduit l'idée de créer une variable globale dans un sub. Dans ce cas, l'exitence de la variable ferait une erreur si elle était re-dimensionné (la prochaine fois, à l'entrée). J'ai trouvé que le code de Klaus n'a pas de fonctionner correctement, mais la méthode est bonne. Il ne fonctionne que, autant que je peux dire, si la variable est libéré et re-créé à chaque fois. Je peux me tromper, mais j'ai essayé sans chacune de ces étapes (lignes, commandes) et il échoue.

Correction: Ah non, désolé, il semble que je me suis trompé sur la "free". Ce n'est pas nécessaire. Le code de Klaus travaille sans elle. Apparemment, il faut toujours vérifier si elle existe avant dim.

J'ai appris beaucoup de choses aujourd'hui, merci.

treehouse a écrit:

Saviez-vous aussi que les sous-programmes peuvent prendre $ ou% comme leur nom?

Le nom d’un sous-programme (SUB ou LABEL ou celui d’une variable ou objet etc.)  est un identificateur qui sert à identifier de façon univoque ce sous-programme (ou les autres objets).

Il doit être construit en respectant la syntaxe :

L’identificateur d’une variable ou d’une SUB peut contenir les 26 lettres (minuscules ou majuscules : c’est la même chose), les 10 chiffres arabes ( 0 à 9) et le caractère de soulignement _ (underscore) . Le 1er caractère doit obligatoirement être une lettre. Tout autre caractère provoquera une erreur.

Exeption
On peut prendre plus de liberté avec les identificateurs d’un LABEL : tout caractère est accepté, même à la 1ere position.

Code:

label fin
label 1
label _1
label a$
label $
label !
label [

gosub a$
gosub 1
gosub _1
gosub $
gosub !
gosub [
gosub fin


end
fin:
  message "End"
  terminate
return

1:
  message "Je contiune"
return

_1:
  message "C'est la suite"
return

a$:
  message "je suis ici"
return

$:
  message "cet identificateur est valide"
return

!:
  message "c'est aussi valide"
return


[:
  message "Toujours valide"
return

Tu as raison, Papydall.

Mais, en particulier venant de toi, j'aurais aimé un peu d'approfondissement, pour introduire quelques conventions concernant la "bonne pratique de programmation", en particulier en vue de la lisibilité par d'autres, et en vue de la maintenabilité d'un code.

Car, si tout ou presque est autorisé, il convient tout de même de s'imposer quelques règles simples et fortes, sur la nomination des variables, des labels, des procédures, ainsi que sur la présentation graphique (indentation, ...) d'un code. Et ce particulièrement à l'intention d'un nouveau venu sur Panoramic...

Klaus,  tu as raison.
« La bonne pratique de programmation » est fortement souhaitée.
Bien que ces deux déclarations soient correctes,
je préfère : LABEL Calcul_de_la_surface_et_du_volume_d_une_sphere
à ceci : LABEL (