So what ?
C'est exactement la même chose que ce que tu as écrit 5 posts plus haut.
Y'a juste ta variable valeurretour qui s'est transformée en valeurretour1.
Le résultat n'est pas dépendant du nom de la variable (!!)
Donc le résultat est le même.
Bureau : Win10 64bits
Maison : Macbook Pro M3 16" SSD 512 Go / Ram 24 Go - iPad Pro 32 Go (pour madame) - iPhone 15 Pro Max 256 Go
Mais bon, ton code d'exemple est un mauvais exemple dans la mesure où tu déclares préalablement en Global valeurretour2
Donc, plutôt comme ceci (parmi bien d'autres solutions) :
valeurorigine.a=50
Procedure MultiplicationPar2(valeur.i)
valeur*2 ; pareil à valeur=valeur * 2 ; ces deux lignes peuvent être remplacées directement par ProcedureReturn valeur*2
ProcedureReturn valeur
EndProcedure
Debug MultiplicationPar2(valeurorigine)
; ou encore
valeurorigine=MultiplicationPar2(valeurorigine)
debug valeurorigine
Dayvid a écrit :Bin voilà, donc j'ai du raté quelque chose
Ces notions ne sont pas si faciles; je me souviens du temps qu'il m'a fallu pour comprendre les tableaux, les listes chaînées, les pointeurs, quand j'étais tout jeune... Les paramètres de procédures embrouillent les choses, surtout quand il y a des globals, des shared, etc.
Un programme bien structuré doit être découpé de façon à limiter les actions répétitives ; c'est pour cela qu'on crée des procédures. On leur passe les paramètres pour qu'elles s'adaptent, et elles peuvent modifier des choses, par exemple des variables qu'elles partagent avec d'autres procédures, ou avec le programme entier, ou des zones mémoires.
C'est au programmeur de dire ce qu'elles peuvent modifier. Normalement, une procédure ne peut accéder qu'aux variables qui sont déclarées dans son "périmètre", ou celles qui lui sont passées en paramètres. C'est une sorte de sécurité. En programmation objet, ces notions sont poussées très loin, mais tu verras ça plus tard. En assembleur, tout cela n'existe pas, un programme peut tout modifier. Un langage de haut niveau (comme PB, le C, le Pascal, Python, Java...) est là pour assister le programmeur, lui éviter de faire des bêtises, ajouter un niveau d'abstraction en simplifiant les concepts.
Ensuite, il faut distinguer deux choses : les fonctions et les procédures. Une fonction renvoie une valeur, en se servant de ProcedureReturn. Par exemple Random() ou Sin(). On peut se servir d'une fonction presque comme une variable, faire des opérations dessus, etc. Une procédure effectue un certain nombre de tâches, sans forcément renvoyer de valeurs. En PB, fonctions et procédures sont confondues, on n'utilise que le terme de procédure. Si on n'utilise pas ProcedureReturn, une procédure renvoie quand même quelque chose : 0.
Global a ; a est accessible par toutes les procédures et le programme principal
Shared b ; dans une procédure, b devient accessible
c.i = 0 ; c n'est accessible que dans le périmètre actuel (programme principal ou procédure)
Une commande est une instruction native qui exécute (une) certaine(s) tâche(s) sans retourner de résultat. Ex : End
Une fonction est une instruction native qui exécute (une) certaine(s) tâche(s) et retourne un résultat. Ex : resultat=Random()
Donc, selon la manière dont tu crées une procédure sous PB, cette dernière équivaut soit à une commande soit à une fonction :
Exemple de procédure utilisée comme une commande (et donc pour laquelle tu n'attends pas de résultat en retour) :
Procedure FonctionX()
resultat=MessageRequester("Titre","Veux-tu vraiment quitter ce programme ?",#PB_MessageRequester_YesNo)
ProcedureReturn resultat
EndProcedure
While FonctionX()=#PB_MessageRequester_No
Wend
Cette procédure ne te permet donc que de te retourner, via ProcedureReturn, qu'un seul résultat. (Note aux pointilleux : J'omets volontairement la technique du StringField)
Maintenant, si tu souhaites qu'une procédure, qu'elle soit utilisée comme une commande ou comme une fonction, modifie des variables dites "hors de portée" (c-à-d non déclarées à l'intérieur de la procédure) ou retourne plusieurs résultats, tu dois utiliser des commandes comme Global, Shared ou des pointeurs...
Dernière modification par boddhi le mer. 18/mai/2011 21:17, modifié 2 fois.
Le mieux Dayvid serait d'utiliser un code comme mon exemple, à la page principale. Passer par des pointeurs permet beaucoup de souplesse et, une fois assimilé, simplifie de beaucoup le code et le fonctionnement du programme. Je ne peux que te conseiller ce lien et ensuite celui-ci. Il est pour le C mais la théorie reste la même. Concentre-toi donc plus sur le texte.
Juste une remarque en passant :
Quoique l'on pense de VB, il a truc très intéressant au niveau de ses procedures (sub ou function), ce sont les mots-clés ByVal et ByRef, très très pratiques.
ByVal indique que c'est la valeur de la variable qui est passée à l'argument, donc tout changement de cette valeur dans la procédure n'affectera pas la valeur de la variable passée en argument, à l'instar de PB.
ByRef transmet la référence de la variable (l'équivalent du pointeur sous PB), laquelle sera donc affectée par tout changement à l'intérieur de la procédure, à l'instar de Static.
Je trouve que pour certains usages, c'est quand même plus simple et qu'un équivalent sous PB ne serait pas inintéressant, même si il est vrai que l'on peut faire autrement...
Oulà! Je n'avais pas vu ce tutoriel! Merci Boddhi!
Et il est vrai qu'un équivalent de ByRef et de ByVal dans PureBasic simplifierait bien des choses pour les débutants, et même pour la clarté du code en général, je trouve.
Warkering a écrit :Oulà! Je n'avais pas vu ce tutoriel! Merci Boddhi!
Et il est vrai qu'un équivalent de ByRef et ByVal dans PureBasic simplifierait bien des choses pour les débutants, et même pour la clarté du code en général, je trouve.
ha bon ?
tu trouve que d'ajouter ByRef et de ByVal simplifierai les chose ?
le fait Ajouter une raison de confusion supplémentaire , serai un plus ?
il n'y a pas plus gerbant que ces notions spécifique a VB !
pourquoi pas demander qu'on soit obligé de faire suivre un runtime avec le code tant qu'on y est !
programme en VB , tu aura tout loisir de jouer avec ces notions que tu trouve simple