Par exemple, mon module volonté doit déduire les propriétés de n
combinaisons :
public compteur as integer
module volonté :
public sub simulation()
compteur=compteur+1
déduction.exécution(compteur)
if compteur=n then
end
endif
end sub
module déduction :
public sub exécution(x)
blablabla
volonté.simulation
end sub
Sauf que là, j'ai mis la condition de sortie après.
Par exemple, mon module volonté doit déduire les propriétés de n
combinaisons :
public compteur as integer
module volonté :
public sub simulation()
compteur=compteur+1
déduction.exécution(compteur)
if compteur=n then
end
endif
end sub
module déduction :
public sub exécution(x)
blablabla
volonté.simulation
end sub
Sauf que là, j'ai mis la condition de sortie après.
Par exemple, mon module volonté doit déduire les propriétés de n
combinaisons :
public compteur as integer
module volonté :
public sub simulation()
compteur=compteur+1
déduction.exécution(compteur)
if compteur=n then
end
endif
end sub
module déduction :
public sub exécution(x)
blablabla
volonté.simulation
end sub
Sauf que là, j'ai mis la condition de sortie après.
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter l a
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sin on la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui se ra
donc commune à toute les instances de simulation, plutôt qu'une varia ble
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter l a
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sin on la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui se ra
donc commune à toute les instances de simulation, plutôt qu'une varia ble
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter l a
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sin on la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui se ra
donc commune à toute les instances de simulation, plutôt qu'une varia ble
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Salut fraction
Je pense comme Vincent que tu devrais nous faire quand une petite démo de
tes appels
tu peux shunter la partie appel de procédures dans le même module.
mais nous faire voir quand même comment c'est construit..
Car si tu appelles ta procédure à l'intérieur d'une procédure "maîtresse"
il
n'y a aucune raison que cela ne revienne pas.
As tu essayé le mode pas à pas. c'est sans doute fastidieux, mais très
intéressant pour debugger.
essaie en simplifiant de nous faire voir un bout de ta démarche.
Driss
Salut fraction
Je pense comme Vincent que tu devrais nous faire quand une petite démo de
tes appels
tu peux shunter la partie appel de procédures dans le même module.
mais nous faire voir quand même comment c'est construit..
Car si tu appelles ta procédure à l'intérieur d'une procédure "maîtresse"
il
n'y a aucune raison que cela ne revienne pas.
As tu essayé le mode pas à pas. c'est sans doute fastidieux, mais très
intéressant pour debugger.
essaie en simplifiant de nous faire voir un bout de ta démarche.
Driss
Salut fraction
Je pense comme Vincent que tu devrais nous faire quand une petite démo de
tes appels
tu peux shunter la partie appel de procédures dans le même module.
mais nous faire voir quand même comment c'est construit..
Car si tu appelles ta procédure à l'intérieur d'une procédure "maîtresse"
il
n'y a aucune raison que cela ne revienne pas.
As tu essayé le mode pas à pas. c'est sans doute fastidieux, mais très
intéressant pour debugger.
essaie en simplifiant de nous faire voir un bout de ta démarche.
Driss
Salut Fraction
OK pour cela.
Regarde quand même tout de suite si tu peux comiler ton projet.
Cela serait dommage que tu avance de plus en plus dans ta parade et que tu
sois bloqué à la compilation.
Driss
Salut Fraction
OK pour cela.
Regarde quand même tout de suite si tu peux comiler ton projet.
Cela serait dommage que tu avance de plus en plus dans ta parade et que tu
sois bloqué à la compilation.
Driss
Salut Fraction
OK pour cela.
Regarde quand même tout de suite si tu peux comiler ton projet.
Cela serait dommage que tu avance de plus en plus dans ta parade et que tu
sois bloqué à la compilation.
Driss
Je ne comprends pas le problème. Qu'entends-tu par "appeler un module"?
En général, on appelle une fonction d'un module, pas le module lui-même.
Et le retour d'un fonction est automatique (sauf si la fonction contient
une boucle infinie).
Peux-tu donner un exemple de code?
Vincent Guichard
Oui, tu as raison. J'appelle une procédure d'un module, elle-même
appelle d'autres procédures de ce même module. Mais une fois cette
exécution terminée, elle ne renvoie pas la main. Le code est trop
compliqué pour l'écrire ici.
J'ai peut-être fait une erreur.
Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
variable publique et en demandant à la procédure fille de revenir en
arrière.
Je ne comprends pas le problème. Qu'entends-tu par "appeler un module"?
En général, on appelle une fonction d'un module, pas le module lui-même.
Et le retour d'un fonction est automatique (sauf si la fonction contient
une boucle infinie).
Peux-tu donner un exemple de code?
Vincent Guichard
Oui, tu as raison. J'appelle une procédure d'un module, elle-même
appelle d'autres procédures de ce même module. Mais une fois cette
exécution terminée, elle ne renvoie pas la main. Le code est trop
compliqué pour l'écrire ici.
J'ai peut-être fait une erreur.
Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
variable publique et en demandant à la procédure fille de revenir en
arrière.
Je ne comprends pas le problème. Qu'entends-tu par "appeler un module"?
En général, on appelle une fonction d'un module, pas le module lui-même.
Et le retour d'un fonction est automatique (sauf si la fonction contient
une boucle infinie).
Peux-tu donner un exemple de code?
Vincent Guichard
Oui, tu as raison. J'appelle une procédure d'un module, elle-même
appelle d'autres procédures de ce même module. Mais une fois cette
exécution terminée, elle ne renvoie pas la main. Le code est trop
compliqué pour l'écrire ici.
J'ai peut-être fait une erreur.
Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
variable publique et en demandant à la procédure fille de revenir en
arrière.
Le 23/12/2009 15:35, fraction a écrit :
>> Je ne comprends pas le problème. Qu'entends-tu par "appeler un module"?
>> En général, on appelle une fonction d'un module, pas le module
>> lui-même.
>> Et le retour d'un fonction est automatique (sauf si la fonction
>> contient
>> une boucle infinie).
>> Peux-tu donner un exemple de code?
>> Vincent Guichard
> Oui, tu as raison. J'appelle une procédure d'un module, elle-même
> appelle d'autres procédures de ce même module. Mais une fois cette
> exécution terminée, elle ne renvoie pas la main. Le code est trop
> compliqué pour l'écrire ici.
> J'ai peut-être fait une erreur.
> Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
> variable publique et en demandant à la procédure fille de revenir en
> arrière.
Comment donc peux-tu demander à la procédure fille de revenir en
arrière? Et comment une variable publique peut-elle bien corriger un
problème tel que tu le décris? Je subodore un grave problème de
conception de l'application. Faute du code complet, peut être
pourrais-tu indiquer une pile des appels? Et donner la "parade" que tu
as trouvé?
Voici les choses telles que je les comprends, avec les informations
limitées que j'ai. Tu appeles une fonction (ou une procédure) qui se
trouves dans ton module. Cette fonction ne retourne jamais: Pourquoi?
En général, c'est qu'il y a une boucle infinie (par exemple, la
condition de fin de boucle ne se produit pas). Une des possibilités qui
me viennent à l'esprit est que tu travailles sur deux threads avec des
variables portant le même nom, et que tu t'attends en modifiant l'une à
voir l'autre se modifier.
Pour sortir d'une boucle tu n'as pas 36 possibilités:
+ la condition de sortie se produit (normal)
+ un appel Exit pour sortir proprement avant que la condition soit
réalisée
+ un appel Goto vers un label en dehors de la boucle (beurk, mais
parfois utile si on sait ce qu'on fait)
Ce dont j'ai peur, c'est que la parade que tu as trouvé consiste en
l'appel de la procédure maitresse, en utilisant la variable publique
pour savoir que tu reviens de la procédure du module. Et ca, c'est très
dangereux, parce que ça veux dire que tu vas empiler les appels et finir
par cracher l'appli, faute de mémoire.
Vincent Guichard
Le 23/12/2009 15:35, fraction a écrit :
>> Je ne comprends pas le problème. Qu'entends-tu par "appeler un module"?
>> En général, on appelle une fonction d'un module, pas le module
>> lui-même.
>> Et le retour d'un fonction est automatique (sauf si la fonction
>> contient
>> une boucle infinie).
>> Peux-tu donner un exemple de code?
>> Vincent Guichard
> Oui, tu as raison. J'appelle une procédure d'un module, elle-même
> appelle d'autres procédures de ce même module. Mais une fois cette
> exécution terminée, elle ne renvoie pas la main. Le code est trop
> compliqué pour l'écrire ici.
> J'ai peut-être fait une erreur.
> Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
> variable publique et en demandant à la procédure fille de revenir en
> arrière.
Comment donc peux-tu demander à la procédure fille de revenir en
arrière? Et comment une variable publique peut-elle bien corriger un
problème tel que tu le décris? Je subodore un grave problème de
conception de l'application. Faute du code complet, peut être
pourrais-tu indiquer une pile des appels? Et donner la "parade" que tu
as trouvé?
Voici les choses telles que je les comprends, avec les informations
limitées que j'ai. Tu appeles une fonction (ou une procédure) qui se
trouves dans ton module. Cette fonction ne retourne jamais: Pourquoi?
En général, c'est qu'il y a une boucle infinie (par exemple, la
condition de fin de boucle ne se produit pas). Une des possibilités qui
me viennent à l'esprit est que tu travailles sur deux threads avec des
variables portant le même nom, et que tu t'attends en modifiant l'une à
voir l'autre se modifier.
Pour sortir d'une boucle tu n'as pas 36 possibilités:
+ la condition de sortie se produit (normal)
+ un appel Exit pour sortir proprement avant que la condition soit
réalisée
+ un appel Goto vers un label en dehors de la boucle (beurk, mais
parfois utile si on sait ce qu'on fait)
Ce dont j'ai peur, c'est que la parade que tu as trouvé consiste en
l'appel de la procédure maitresse, en utilisant la variable publique
pour savoir que tu reviens de la procédure du module. Et ca, c'est très
dangereux, parce que ça veux dire que tu vas empiler les appels et finir
par cracher l'appli, faute de mémoire.
Vincent Guichard
Le 23/12/2009 15:35, fraction a écrit :
>> Je ne comprends pas le problème. Qu'entends-tu par "appeler un module"?
>> En général, on appelle une fonction d'un module, pas le module
>> lui-même.
>> Et le retour d'un fonction est automatique (sauf si la fonction
>> contient
>> une boucle infinie).
>> Peux-tu donner un exemple de code?
>> Vincent Guichard
> Oui, tu as raison. J'appelle une procédure d'un module, elle-même
> appelle d'autres procédures de ce même module. Mais une fois cette
> exécution terminée, elle ne renvoie pas la main. Le code est trop
> compliqué pour l'écrire ici.
> J'ai peut-être fait une erreur.
> Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
> variable publique et en demandant à la procédure fille de revenir en
> arrière.
Comment donc peux-tu demander à la procédure fille de revenir en
arrière? Et comment une variable publique peut-elle bien corriger un
problème tel que tu le décris? Je subodore un grave problème de
conception de l'application. Faute du code complet, peut être
pourrais-tu indiquer une pile des appels? Et donner la "parade" que tu
as trouvé?
Voici les choses telles que je les comprends, avec les informations
limitées que j'ai. Tu appeles une fonction (ou une procédure) qui se
trouves dans ton module. Cette fonction ne retourne jamais: Pourquoi?
En général, c'est qu'il y a une boucle infinie (par exemple, la
condition de fin de boucle ne se produit pas). Une des possibilités qui
me viennent à l'esprit est que tu travailles sur deux threads avec des
variables portant le même nom, et que tu t'attends en modifiant l'une à
voir l'autre se modifier.
Pour sortir d'une boucle tu n'as pas 36 possibilités:
+ la condition de sortie se produit (normal)
+ un appel Exit pour sortir proprement avant que la condition soit
réalisée
+ un appel Goto vers un label en dehors de la boucle (beurk, mais
parfois utile si on sait ce qu'on fait)
Ce dont j'ai peur, c'est que la parade que tu as trouvé consiste en
l'appel de la procédure maitresse, en utilisant la variable publique
pour savoir que tu reviens de la procédure du module. Et ca, c'est très
dangereux, parce que ça veux dire que tu vas empiler les appels et finir
par cracher l'appli, faute de mémoire.
Vincent Guichard
On 23 déc, 17:35, Vincent Guichard wrote:
> Le 23/12/2009 15:35, fraction a écrit :
> >> Je ne comprends pas le problème. Qu'entends-tu par "appeler un
> >> module"?
> >> En général, on appelle une fonction d'un module, pas le module
> >> lui-même.
> >> Et le retour d'un fonction est automatique (sauf si la fonction
> >> contient
> >> une boucle infinie).
> >> Peux-tu donner un exemple de code?
> >> Vincent Guichard
> > Oui, tu as raison. J'appelle une procédure d'un module, elle-même
> > appelle d'autres procédures de ce même module. Mais une fois cette
> > exécution terminée, elle ne renvoie pas la main. Le code est trop
> > compliqué pour l'écrire ici.
> > J'ai peut-être fait une erreur.
> > Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
> > variable publique et en demandant à la procédure fille de revenir en
> > arrière.
> Comment donc peux-tu demander à la procédure fille de revenir en
> arrière? Et comment une variable publique peut-elle bien corriger un
> problème tel que tu le décris? Je subodore un grave problème de
> conception de l'application. Faute du code complet, peut être
> pourrais-tu indiquer une pile des appels? Et donner la "parade" que tu
> as trouvé?
> Voici les choses telles que je les comprends, avec les informations
> limitées que j'ai. Tu appeles une fonction (ou une procédure) qui se
> trouves dans ton module. Cette fonction ne retourne jamais: Pourquoi?
> En général, c'est qu'il y a une boucle infinie (par exemple, la
> condition de fin de boucle ne se produit pas). Une des possibilités qui
> me viennent à l'esprit est que tu travailles sur deux threads avec des
> variables portant le même nom, et que tu t'attends en modifiant l'une à
> voir l'autre se modifier.
> Pour sortir d'une boucle tu n'as pas 36 possibilités:
> + la condition de sortie se produit (normal)
> + un appel Exit pour sortir proprement avant que la condition soit
> réalisée
> + un appel Goto vers un label en dehors de la boucle (beurk, mais
> parfois utile si on sait ce qu'on fait)
> Ce dont j'ai peur, c'est que la parade que tu as trouvé consiste en
> l'appel de la procédure maitresse, en utilisant la variable publique
> pour savoir que tu reviens de la procédure du module. Et ca, c'est très
> dangereux, parce que ça veux dire que tu vas empiler les appels et finir
> par cracher l'appli, faute de mémoire.
> Vincent Guichard
Par exemple, mon module volonté doit déduire les propriétés de n
combinaisons :
public compteur as integer
module volonté :
public sub simulation()
compteur=compteur+1
déduction.exécution(compteur)
if compteur=n then
end
endif
end sub
module déduction :
public sub exécution(x)
blablabla
volonté.simulation
end sub
On 23 déc, 17:35, Vincent Guichard <vg.bleuciel...@wanadoo.fr> wrote:
> Le 23/12/2009 15:35, fraction a écrit :
> >> Je ne comprends pas le problème. Qu'entends-tu par "appeler un
> >> module"?
> >> En général, on appelle une fonction d'un module, pas le module
> >> lui-même.
> >> Et le retour d'un fonction est automatique (sauf si la fonction
> >> contient
> >> une boucle infinie).
> >> Peux-tu donner un exemple de code?
> >> Vincent Guichard
> > Oui, tu as raison. J'appelle une procédure d'un module, elle-même
> > appelle d'autres procédures de ce même module. Mais une fois cette
> > exécution terminée, elle ne renvoie pas la main. Le code est trop
> > compliqué pour l'écrire ici.
> > J'ai peut-être fait une erreur.
> > Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
> > variable publique et en demandant à la procédure fille de revenir en
> > arrière.
> Comment donc peux-tu demander à la procédure fille de revenir en
> arrière? Et comment une variable publique peut-elle bien corriger un
> problème tel que tu le décris? Je subodore un grave problème de
> conception de l'application. Faute du code complet, peut être
> pourrais-tu indiquer une pile des appels? Et donner la "parade" que tu
> as trouvé?
> Voici les choses telles que je les comprends, avec les informations
> limitées que j'ai. Tu appeles une fonction (ou une procédure) qui se
> trouves dans ton module. Cette fonction ne retourne jamais: Pourquoi?
> En général, c'est qu'il y a une boucle infinie (par exemple, la
> condition de fin de boucle ne se produit pas). Une des possibilités qui
> me viennent à l'esprit est que tu travailles sur deux threads avec des
> variables portant le même nom, et que tu t'attends en modifiant l'une à
> voir l'autre se modifier.
> Pour sortir d'une boucle tu n'as pas 36 possibilités:
> + la condition de sortie se produit (normal)
> + un appel Exit pour sortir proprement avant que la condition soit
> réalisée
> + un appel Goto vers un label en dehors de la boucle (beurk, mais
> parfois utile si on sait ce qu'on fait)
> Ce dont j'ai peur, c'est que la parade que tu as trouvé consiste en
> l'appel de la procédure maitresse, en utilisant la variable publique
> pour savoir que tu reviens de la procédure du module. Et ca, c'est très
> dangereux, parce que ça veux dire que tu vas empiler les appels et finir
> par cracher l'appli, faute de mémoire.
> Vincent Guichard
Par exemple, mon module volonté doit déduire les propriétés de n
combinaisons :
public compteur as integer
module volonté :
public sub simulation()
compteur=compteur+1
déduction.exécution(compteur)
if compteur=n then
end
endif
end sub
module déduction :
public sub exécution(x)
blablabla
volonté.simulation
end sub
On 23 déc, 17:35, Vincent Guichard wrote:
> Le 23/12/2009 15:35, fraction a écrit :
> >> Je ne comprends pas le problème. Qu'entends-tu par "appeler un
> >> module"?
> >> En général, on appelle une fonction d'un module, pas le module
> >> lui-même.
> >> Et le retour d'un fonction est automatique (sauf si la fonction
> >> contient
> >> une boucle infinie).
> >> Peux-tu donner un exemple de code?
> >> Vincent Guichard
> > Oui, tu as raison. J'appelle une procédure d'un module, elle-même
> > appelle d'autres procédures de ce même module. Mais une fois cette
> > exécution terminée, elle ne renvoie pas la main. Le code est trop
> > compliqué pour l'écrire ici.
> > J'ai peut-être fait une erreur.
> > Ça m'arrive rarement. Et j'ai trouvé la parade en déclarant une
> > variable publique et en demandant à la procédure fille de revenir en
> > arrière.
> Comment donc peux-tu demander à la procédure fille de revenir en
> arrière? Et comment une variable publique peut-elle bien corriger un
> problème tel que tu le décris? Je subodore un grave problème de
> conception de l'application. Faute du code complet, peut être
> pourrais-tu indiquer une pile des appels? Et donner la "parade" que tu
> as trouvé?
> Voici les choses telles que je les comprends, avec les informations
> limitées que j'ai. Tu appeles une fonction (ou une procédure) qui se
> trouves dans ton module. Cette fonction ne retourne jamais: Pourquoi?
> En général, c'est qu'il y a une boucle infinie (par exemple, la
> condition de fin de boucle ne se produit pas). Une des possibilités qui
> me viennent à l'esprit est que tu travailles sur deux threads avec des
> variables portant le même nom, et que tu t'attends en modifiant l'une à
> voir l'autre se modifier.
> Pour sortir d'une boucle tu n'as pas 36 possibilités:
> + la condition de sortie se produit (normal)
> + un appel Exit pour sortir proprement avant que la condition soit
> réalisée
> + un appel Goto vers un label en dehors de la boucle (beurk, mais
> parfois utile si on sait ce qu'on fait)
> Ce dont j'ai peur, c'est que la parade que tu as trouvé consiste en
> l'appel de la procédure maitresse, en utilisant la variable publique
> pour savoir que tu reviens de la procédure du module. Et ca, c'est très
> dangereux, parce que ça veux dire que tu vas empiler les appels et finir
> par cracher l'appli, faute de mémoire.
> Vincent Guichard
Par exemple, mon module volonté doit déduire les propriétés de n
combinaisons :
public compteur as integer
module volonté :
public sub simulation()
compteur=compteur+1
déduction.exécution(compteur)
if compteur=n then
end
endif
end sub
module déduction :
public sub exécution(x)
blablabla
volonté.simulation
end sub
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter la
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sinon la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui sera
donc commune à toute les instances de simulation, plutôt qu'une variable
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter la
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sinon la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui sera
donc commune à toute les instances de simulation, plutôt qu'une variable
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter la
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sinon la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui sera
donc commune à toute les instances de simulation, plutôt qu'une variable
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Salut Fraction
OK pour cela.
Regarde quand même tout de suite si tu peux comiler ton projet.
Cela serait dommage que tu avance de plus en plus dans ta parade et que tu
sois bloqué à la compilation.
Driss
Salut Fraction
OK pour cela.
Regarde quand même tout de suite si tu peux comiler ton projet.
Cela serait dommage que tu avance de plus en plus dans ta parade et que tu
sois bloqué à la compilation.
Driss
Salut Fraction
OK pour cela.
Regarde quand même tout de suite si tu peux comiler ton projet.
Cela serait dommage que tu avance de plus en plus dans ta parade et que tu
sois bloqué à la compilation.
Driss
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter la
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sinon la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui sera
donc commune à toute les instances de simulation, plutôt qu'une variable
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter la
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sinon la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui sera
donc commune à toute les instances de simulation, plutôt qu'une variable
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
Le 23/12/2009 17:52, fraction a écrit :
>> Par exemple, mon module volonté doit déduire les propriétés de n
>> combinaisons :
>> public compteur as integer
>> module volonté :
>> public sub simulation()
>> compteur=compteur+1
>> déduction.exécution(compteur)
>> if compteur=n then
>> end
>> endif
>> end sub
>> module déduction :
>> public sub exécution(x)
>> blablabla
>> volonté.simulation
>> end sub
> Sauf que là, j'ai mis la condition de sortie après.
Si j'analyse bien ton code, il va empiler les appels à exectution et à
simulation de façon infinie (la condition de terminaison (end) n'arrive
jamais puisque tu appelles TOUJOURS execution avant, relancant par la
même une nouvelle instance de simulation). Tu va finir par exploser la
pile d'appel (si cela n'explose pas avant autre part).
Par ailleurs, End quitte le programme, pas la procédure (pour quitter la
procédure c'est Exit Sub).
Ensuite, si tu modifie x dans le blablabla d'execution, vérifie que x
est passé par référence si tu veux que compteur soit modifié (sinon la
modification restera locale à cette instance de execution).
Enfin, Si tu dois vraiment utiliser un compteur et que celui-ci n'est
accédé directement que dans simulation, utilise de préférence une
variable statique propre à la procédure (voir mot clef static) qui sera
donc commune à toute les instances de simulation, plutôt qu'une variable
publique.
Sur ce, je pars en vacances jusqu'au 04/01
Bonnes fêtes à tous,
Vincent Guichard
