Cases dans une procedure, ou procedures dans un select ?

[Ouaf-Ouaf]

Salut,

la question est dans le titre.

Malgré mes recherches, je ne sais pas bien comment Pure traite les procedures. J'ai crus comprendre qu'il y avait une histoire de depliage de cette partie de code.
Par là j'entends, à chaque appel de la procedure, le processeur la compilerait, ou en tout cas f'rait un travail dessus.
D'ou ma question..

Code : Tout sélectionner

Procedure Truc( Option )


  Select Option
  
         Case 01 : ...
         Case 02 : ...
         Case 03 : ...
         Case 04 : ...
         Case 05 : ...
  
  EndSelect


EndProcedure



For A = 1 To 5 : Truc( A )  : Next A

Içi, ça demenderait au compilo de "deplier" cinqs fois un code, dont on ne necessite qu'un cinquième.. Alors que le contraire :

Code : Tout sélectionner

Procedure Truc_1( )

...

EndProcedure

Procedure Truc_2( )

...

EndProcedure

Etc.


For Option = 1 To 5

  Select Option
  
      Case 01 : Truc_1()
      Case 02 : Truc_2()
      Case 03 : Truc_3()
      Case 04 : Truc_4()
      Case 05 : Truc_5()
  
  EndSelect

Next Option

Demande donc au compilo de generer uniquement ce qui est necessaire ?


Ca me parait clair quand je l'ecris.. Mais etant de nature sceptique ...

La deuxieme solution est bien la meilleure ?

[warang580]

Déjà tu peux voir que le code 2 est plus long que le 1. Mais c'est parce que dans le code 2, tu fais le travail du code 1. A la base, les procedures sont là pour alléger le CODE, pas la vitesse. La méthode 1 est beaucoup plus compréhensible d'ailleurs. En fait, ça dépend comment tu comprends ton code. Si tu y arrives mieux avec la méthode 2, prends là.

Mais cette question n'est valable que si tu connais les valeurs que tu passes en paramètres.

Si tu fais ça par exemple, ça n'a plus d'intérêt :

Code : Tout sélectionner

; "Méthode 1"

Procedure Inc(nombre) ; Retourne le nombre + 1 (Inc = Incrémente)

  ProcedureReturn nombre + 1

EndProcedure

Debug Inc(10) ; 11

; "Méthode 2"

nombre = 10

Select nombre

  Case 0 : nombre = 1
  Case 1 : nombre = 2
  Case 2 : nombre = 3
  
  ; ETC ....
  ; Pas pratique !

EndSelect

Debug nombre

J'espère que tu as compris ce que j'ai voulu dire

[Ouaf-Ouaf]

Lut,

merci pour la rep. Le truc c'est que j'faisais (peut-être) une confusion avec un truc que j'ai lus sur les procedures ( quelques chose rends ça plus lent a utiliser que l'même code dans un gosub ou un macro..)

Après pfff.. Je me souviens plus tres bien comment je suis arrivé à cette conclusion..

Sinon oui les procedures servent a remplir des arrays de façon bien definie dans un cas bien specifique, et c'est pas du tout heu.. mecanisable

[Backup]

Lut,

merci pour la rep. Le truc c'est que j'faisais (peut-être) une confusion avec un truc que j'ai lus sur les procedures ( quelques chose rends ça plus lent a utiliser que l'même code dans un gosub ou un macro..)

oui ! cela viens du fait qu'une procedure "depose" les arguments sur la pile
et sauvegarde l'etat des registres et recupere ceux-ci a la fin de la procedure , ce qui occasionne une "perte" de temps

un sous-prg lui execute un Saut (Gosub) vers une portion de code qui est executé , puis RETURN a son point de depart !!
aucun registre sauvé, ni récupéré !!


une procedure sauve l'etat des registres, parcequ'elle peut etre Récursive

[Ouaf-Ouaf]

Yep, c'est ce que j'avais vaguement compris.
Maintenant la "pile" j'ai aucune idée de ce que ça represente. Mais bon soit, expliqué comme tu l'as fait c'est quand même un poil mieux.

Donc le calcul, la perte de temps, ne concerne pas le code contenus dans la procedure, mais juste l'etat du registre à son appel donc ?

La procedure occupe une place sur "la pile" et le prog doit sauvegarder la portion de registre de la taille qui serat squattée par la procedure ?

Dans cette logique, plus une procedure serait gourmande en place ... physique .. sur le processeur ( c'est ça au moins ? ), plus l'enregistrement et la restitution serait "longue" ?

donc dans ce cas, vaudrait carrement mieux faire bosser le proc sur des petites procedures en evitant le superflu ?




Pour l instant j'ai retenus la methode des petites procedures .. Et bon... la difference est imperceptible

Mais bon, y a un truc qui est flou pour moi là avec les procs, j'arrive pas à me representer le problème .. heu ... "physiquement"..
C'est relou !

[Backup]

pour tout comprendre va ici :

Les procedures :
http://www.commentcamarche.net/asm/procedure.php3

et ici pour la pile :
http://www.commentcamarche.net/asm/pile.php3

[Ouaf-Ouaf]

C'est genial merci beaucoup.

Dé-pi-ler ! Ok, je lisais déplier avant -.-

[Backup]

C'est genial merci beaucoup.

Dé-pi-ler ! Ok, je lisais déplier avant -.-

comme ça tu comprends que le temps que perds le system a empiler les valeurs de parametre et l'etat des registre , puis a la sortie de la procedure de tout remettre en place , fait qu'une procedure est plus lente qu'un sous-prg (Gosub-Return) , mais par contre le system des procedures (fonctions) est plus confortable et plus "propre" a programmer, parce que plus clair a relire, mais surtout par l'emploi de variable Locale a la procedure qui permettent d'isoler le travail dans la procedure par rapport a l'exterieur ..

je vais peut etre dire une bêtise, en faisant une analogie avec l'électronique , mais personnellement
je vois une procedure comme un circuit integré !!


1-on applique des valeurs (tension) aux pattes d'entré du circuit
(ce qui correspond aux paramètres d'une procedure)

2-le circuit fait son boulot (porte logique par exemple) , c'est la phase traitement

3-et le circuit donne le résultat du traitement a sa ou ses pattes de Sortie
(tout comme la procedure avec ProcedureReturn)

et tout ce qui se passe dans la procedure (Circuit) est parfaitement invisible au reste de la carte electronique (le programme)

[Ouaf-Ouaf]

Uii j'avais lus ça sur la POO le delire de la fonction comparée au composants electroniques.

C'est net que ça éclaircit 'achement un programme.

C'est peut'être superflu sur un petit programme, mais y a un moment ou ça donne un recul vraiment appreciable.

C'est.. enfin ca depends peut-être des gens.. Mwa ça a donné un coup d'fouet à ma façon de voir mon code. Ca evite un effort de lecture qui s'accroit avec le code -.-.. Fin bref.