variable à definir ...

[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.

[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.

[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.

[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 !!

[Backup]

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 !

[Octavius]

Les gosub/label/return sont plus rapides que les procédures ? Alors à quoi servent les procédures ?

[Guimauve]

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

[Backup]

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..

[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.