PureBasic

dayvid a écrit :Bin voilà, donc j'ai du raté quelque chose

Code : Tout sélectionner

Global valeurretour.a

valeurretour2 = 10

Procedure Test(valeurretour1)
  
  valeurretour2=50
  
EndProcedure

Test(10)

Debug valeurretour2

marche pas

Bref en faite une procedure, c'est une boîte
et aucune variable peut en sortir sauf avec le procedurrerturn

J'ai toujours eu du mal avec ce concept la moi

Marche très bien, si tu définis en global le bon nom de variable : valeurretour2.a

Mais dis-moi, dans ton exemple, elle te sert à quoi, la variable valeurretour1 ???

Ha oui me suis trompé, voilà:

dayvid a écrit :Ha oui me suis trompé, voilà:

Code : Tout sélectionner

Global valeurretour1.a

valeurretour1 = 10

Procedure Test(valeurretour1)
  
  valeurretour1=50
  
EndProcedure

Test(10)

Debug valeurretour1

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.

dayvid a écrit :
Bref en faite une procedure, c'est une boîte
et aucune variable peut en sortir sauf avec le procedurrerturn

ben tu regardera la doc au mot "Shared"

Dayvid a écrit :Bin voilà, donc j'ai du raté quelque chose

Code : Tout sélectionner

Global valeurretour2.a

valeurretour2 = 10

Procedure Test(valeurretour1)

  valeurretour2=50

EndProcedure
Test(10)
Debug valeurretour2

marche pas

Pour la xième fois, si tu veux récupérer le résultat de ta procédure, tu DOIS utiliser ProcedureReturn!!!!
Donc, avant EndProcedure, tu colles : 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) :

Dayvid a écrit :Bin voilà, donc j'ai du raté quelque chose

Code : Tout sélectionner

Debug valeurretour ; donnera bien 5.

Pourquoi 5 ???? Dans ton exemple => 10 !!!!

Espérant, que cette fois-ci, tu auras définitivement compris !!!

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)

En complément de ce qu'a écrit djes :

• 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) : Exemple de procédure utilisée comme une fonction (et donc pour laquelle tu attends un résultat en retour) : 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...

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

Merci boddhi!

Faudra peut-être expliquer longtemps mais ça rentrera vite...

@Warkering : Très didactiques, tes liens...

@dayvid : Un très bon tuto sur les pointeurs également présent sur le forum : http://purebasic.fr/french/viewtopic.php?f=21&t=2397.

C'est grâce à lui que je m'étais familiarisé avec leur utilisation...

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.

Pour les débutants, je ne suis pas sûr! Le plus simple est le mieux. D'ailleurs, faudrait virer les procédures, les structures et les pointeurs!

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