Page 1 sur 1
variable à definir ...
Publié : jeu. 09/août/2007 15:34
par jerexgrz
Code : Tout sélectionner
;Global d1.l
;Global d2.l
;d1= 10
;d2= 24
Macro dead()
d1 = d1 + 1
EndMacro
Procedure Leff()
d2 = d2 +1
EndProcedure
dead()
dead()
dead()
leff()
leff()
leff()
Debug d1
Debug d2
Dans l'exemple ci dessus, il s'agit de definir une variable locale. A chaque appel, elle est remise à 0. Pour eviter, comme en RQ, de perturber l'ensemble du code avec le global.
Chaque fois, qu'on appelle macro dead() : d1 est incrementé
par contre, procedure leff() : d2 est incrementé mais localement !
donc d1 = 3 en global : c'est tout à fait normale !!
donc d2 = 0 en global : c'est tout à fait normale !!
Pourtant, il y a la fonction Protected qui permet de ne pas melanger les 2 variables : local + global ! mais cela ne s'applique qu'aux procedures.
Par contre, dans une macro les variables se melangent.
Ce qui me parait etrange, c'est que l'on peut protected une variable qui est dejà ~locale et que dans macro, on ne puisse pas, mis à part de mettre d1 = 0 au debut de la macro.
Publié : jeu. 09/août/2007 17:01
par Octavius
C'est parce que les macros ne fonctionnent pas comme les procédures.
Une procédure n'est écrite qu'une seule fois dans le code et lorsqu'on l'appelle le code renvoie à l'endroit où elle est.
Au contraire, lors de la compilation, lorsque la macro est appellée le code est recopié à l'endroit de l'appel.
Publié : jeu. 09/août/2007 21:07
par Flype
Octavius a bien expliqué çà.
pour encore mieux comprendre,
voici ce que ton programme devient avant d'être passé au compilateur.
Code : Tout sélectionner
Procedure Leff()
d2 = d2 + 1
EndProcedure
d1 = d1 + 1
d1 = d1 + 1
d1 = d1 + 1
leff()
leff()
leff()
plus de commentaires
plus de macros
plus de debugs
le texte dans la macro est recopié là on l'a demandé.
la procédure, elle, est encore là dans le programme.
d2 est remis a 0 à chaque nouvel appel à leff() puisque d2 'meurt' à la fin de la procédure. sauf en écrivant Global d2 au début du source.
Publié : ven. 10/août/2007 11:32
par jerexgrz
Ok ! je croyais en faite que macro etait plutot comme un goto voire une sorte de label. Car au niveau temps une macro et plus rapide q'une procedure !!

Publié : ven. 10/août/2007 13:20
par Backup
jerexgrz a écrit :Ok ! je croyais en faite que macro etait plutot comme un goto voire une sorte de label. Car au niveau temps une macro et plus rapide q'une procedure !!

c'est pourquoi il existe les sous-prg
(gosub----> label:------- return)
qui sont aussi plus rapide que les procedures, et qui servent exactement a ce que tu veux faire !

Publié : ven. 10/août/2007 13:26
par Octavius
Les gosub/label/return sont plus rapides que les procédures ? Alors à quoi servent les procédures ?
Publié : ven. 10/août/2007 14:08
par Guimauve
Octavius a écrit :Les gosub/label/return sont plus rapides que les procédures ? Alors à quoi servent les procédures ?
1. À rendre le code plus facile à suivre.
2. À rendre le code plus facilement réutilisable d'un programme à un autre.
Pour ce qui est de la rapidité d'exécution moi ça fait presque 5 ans que je programme
avec PB et j'ai jamais eu de problème de manque de vitesse dans mes programmes
et j'utilise uniquement des procédures.
Moi j'aimerais bien savoir sur quel projet vous travaillez pour que tout doit être exécuté
avant même que l'utilisateur est eu le temps de demander au programme de faire un travail.
A+
Guimauve
Publié : ven. 10/août/2007 17:20
par Backup
Guimauve a écrit :
Moi j'aimerais bien savoir sur quel projet vous travaillez pour que tout doit être exécuté
avant même que l'utilisateur est eu le temps de demander au programme de faire un travail.
A+
Guimauve
pour ma part ,un interpreteur !
et encore , j'utilise beaucoup de procedures, malgres tout, pour les raisons que tu invoque..
Publié : ven. 10/août/2007 18:17
par Jacobus
...D'autant que dans les procédures tu peux passer pas mal de paramètres si nécessaire et optimiser un code facilement. Une procédure pouvant servir pour plusieurs fonctions et être utilisées dans les threads.