Portée des variables locales

Bonjour,

A priori elle est prise en compte à l'endroit de sa déclaration, car si
on l'invoque avant ça produit une erreur, toutefois, pour ma part, mettre
des variables à la volée dans le code n'est gère lisible, et question
économie, chercher à économiser une pauvre variable face à la mémoire
gigantesque qu'il y a généralement, n'a plus gère d'utilité...

------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"jean saint jalmes" <jeansaintjalmes@discussions.microsoft.com> a écrit dans
le message de news: 4F76463D-A94E-4E27-9821-42055E57E8E9@microsoft.com...
| Bonjour,
|
| Dans une procédure VB6.0, une variable locale est-elle réservée à partir
de
| l'instruction DIM ou dès le début de la procédure ?
|
| Exemple:
|
| Private Sub MyProcedure(Byval Exists as Boolean)
| if Exists then
| .....
| dim Cumul as Long
| .......
|
| End if
| End Sub
|
| Y a-t'il un intérêt en termes de performances à placer l'instruction DIM à
| cet endroit ou bien la variable est de toute façon réservée dès l'entrée
de
| la procédure ?
|
| Merci d'avance, Jean

jean saint jalmes a écrit :

Bonjour,

Dans une procédure VB6.0, une variable locale est-elle réserv ée à partir de
l'instruction DIM ou dès le début de la procédure ?

Exemple:

Private Sub MyProcedure(Byval Exists as Boolean)
if Exists then
.....
dim Cumul as Long
.......

End if
End Sub

Y a-t'il un intérêt en termes de performances à placer l 'instruction DIM à
cet endroit ou bien la variable est de toute façon réservé e dès l'entrée de
la procédure ?

Merci d'avance, Jean

Je ne sais pas exactement quand la réservation à lieu. A priori je
dirais au moment de la définition*, à cause de l'origine interp rétée du
langage. Ce qui est sûr, c'est que la portée de la déclara tion commence
à l'instruction dim et se fini à la fin de la fonction (et non pas à la
fin du bloc, comme en c par exemple). Du coup, déclarer les variable s au
début de la fonction ou au milieu est surtout une affaire de goû t, à mon
avis.**

Vincent Guichard

* en fait c'est même explicitement dit dans l'aide de l'instruction dim:
"Déclare des variables et attribue de l'espace de stockage"
** à la fin de l'aide, ils indiquent qu'en général les ins tructions dim
sont placées au début de la procédure.

"jean saint jalmes" <jeansaintjalmes@discussions.microsoft.com> wrote in
message news:4F76463D-A94E-4E27-9821-42055E57E8E9@microsoft.com...

Bonjour,

Hello,

Dans une procédure VB6.0, une variable locale est-elle réservée à partir
de
l'instruction DIM ou dès le début de la procédure ?

Exemple:

Private Sub MyProcedure(Byval Exists as Boolean)
if Exists then
.....
dim Cumul as Long
.......

End if
End Sub

La variable est réservée et déclarée à l'endroit de sa déclaration par Dim.
Dans ton exemple, la Variable Cumul existe à part de l'endroit de sa
déclaration.
D'ailleurs, essayer d'y faire référence AVANT le Dim ne compile même
pas. VB te signale : "Variable Not Defined".

En revanche et contrairement au C par exemple, la variable une fois déclarée
existe jusqu'à la fin de la procédure (sauf si elle est statique évidemment,
auquel
cas elle existera toujours au prochain appel, son utilisation restant bien
sur limitée
à la partie de procédure suivant la déclaration).

Donc toujours dans ton exemple, la variable Cumul continue à exister même
après ton End If, alors qu'en C par exemple il existe la notion de portée
limitée
au bloc.

Y a-t'il un intérêt en termes de performances à placer l'instruction DIM à
cet endroit ou bien la variable est de toute façon réservée dès l'entrée
de
la procédure ?

Il y a un intérêt éventuel à déclarer certaines variables purement
utilitaires
au plus près de leur endroit d'utilisation, pour des raisons de lisibilité
et
de limitation d'effets de bord.
Par exemple on pourrait écrire:

Private Sub Command1_Click()
Dim t() As String
Dim ub As Long

t = Split("hello,world", ",")
ub = UBound(t)

Dim i As Long
For i = LBound(t) To ub
Debug.Print t(i)
Next i

Ici on voit en lisant que la variable i est visiblement créée uniquement
pour la boucle, par exemple.

Pour ce qui est des performances, aucun intérêt à priori. Quand bien même le
code
généré serait différent en fonction de l'endroit de la déclaration, le gain
ne sera
pas mesurable de toute façon. Ca pourrait faire une différence sur
l'allocation d'un
énorme tableau mais alors il y a d'autres stratégies d'optimisation dans ce
genre de cas.
Ce qui est sur, c'est que pour une variable de taille raisonnable, ca ne
sera pas mesurable.

Question de style, en VB, on aura plutôt intérêt à se limiter à des
déclarations en tête
de procédure: c'est l'usage standard donc ça assure à priori une meilleure
lisibilité.

Cordialement,

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr

Merci pour toutes vos réponses.

Ok pour le peu d'intérêt en termes de performance pour des variables simples.
Pour la lisibilité, je préfère déclarer la variable dans le bloc ou elle est
utilisée même si cela ne correspond pas à l'usage VB.

Merci à tous.

jean saint jalmes a écrit :

Merci pour toutes vos réponses.

Ok pour le peu d'intérêt en termes de performance pour des variables simples.
Pour la lisibilité, je préfère déclarer la variable dans le bloc ou elle est
utilisée même si cela ne correspond pas à l'usage VB.

Merci à tous.

J'imaginais qu'il ne fallait cependant faire attention à ne pas déclarer
de variables dans des boucles (do ... loop, while ... wend, for ...
next) même à l'intérieur d'un if then else
J'imaginais un système dans lequel la plupart du temps on ne repassait
pas sur le dim et qu'exceptionnellemnt on passait deux fois dessus
déclenchant l'erreur "variable déjà déclarée"

Quelle ne fut pas ma surprise de voir que cela fonctionnait sans
problème. Quelqu'un a-t'il une explication ?

Dans l'exemple ci dessous on peut passer plusieurs fois sur la ligne
Dim Message As String tout en restant dans la même procédure (le même
scope de la variable)


Private Sub Command1_Click()
Dim REP As String

Do

REP = InputBox("chosissez un nombre à 3 chiffres, sauf 000")
If REP = "000" Then
Dim Message As String
Message = "J'avais dit pas 000, recommencez !"
MsgBox Message
ElseIf REP = "111" Then Exit Do
End If
Loop
End Sub

PH wrote:

jean saint jalmes a écrit :

Hello,

J'imaginais qu'il ne fallait cependant faire attention à ne pas
déclarer de variables dans des boucles (do ... loop, while ... wend,
for ... next) même à l'intérieur d'un if then else
J'imaginais un système dans lequel la plupart du temps on ne repassait
pas sur le dim et qu'exceptionnellemnt on passait deux fois dessus
déclenchant l'erreur "variable déjà déclarée"

Quelle ne fut pas ma surprise de voir que cela fonctionnait sans
problème. Quelqu'un a-t'il une explication ?

Bien sur :-)

Tu oublies que VB est compilé, pas interprété.
Lors de la compilation, le compilateur analyse le code
source et génère le code final.

Quand il va voir, un Dim, il va en tenir compte et générer le code
nécessaire
pour réserver de la place pour cette variable dans le code d'init de la
procédure.
Puis il va générer le reste du code utilisant cette variable.
Et c'est tout :-)
L'exécution du programme résultant de ton code source n'a rien à voir avec
le dit code source: c'est tout l'intérêt d'un compilateur.

Note que même le plus minable des interpréteurs saurait aussi gérer ça de
façon
naturelle: il suffit qu'il ait une règle disant : Dans un contexte donné (la
procédure
par exemple, un Dim n'est effectivement exécuté qu'une seule fois).

Cordialement;

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr

Bonjour,

Je crois que, quand tu déclares deux fois une variable de même nom, là
il plante, mais ici, à chaque fois qu'il passe sur Dim il réserve la
variable et l'initialise avec ce que le hasard met dedans, c'est en fait,
non pas comme si tu écrivais plusieurs fois son nom, mais comme si tu
l'initialisais ?

Pour l'InputBox, pas bon, on ne peux plus sortir en abandonnant la
saisie (If REP = "" Then Exit Sub)...

------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"PH" <PH@laposte.net> a écrit dans le message de news:
OR%23TJ6fUJHA.2468@TK2MSFTNGP05.phx.gbl...
| jean saint jalmes a écrit :
| > Merci pour toutes vos réponses.
| >
| > Ok pour le peu d'intérêt en termes de performance pour des variables
simples.
| > Pour la lisibilité, je préfère déclarer la variable dans le bloc ou elle
est
| > utilisée même si cela ne correspond pas à l'usage VB.
| >
| > Merci à tous.
|
|
| J'imaginais qu'il ne fallait cependant faire attention à ne pas déclarer
| de variables dans des boucles (do ... loop, while ... wend, for ...
| next) même à l'intérieur d'un if then else
| J'imaginais un système dans lequel la plupart du temps on ne repassait
| pas sur le dim et qu'exceptionnellemnt on passait deux fois dessus
| déclenchant l'erreur "variable déjà déclarée"
|
| Quelle ne fut pas ma surprise de voir que cela fonctionnait sans
| problème. Quelqu'un a-t'il une explication ?
|
| Dans l'exemple ci dessous on peut passer plusieurs fois sur la ligne
| Dim Message As String tout en restant dans la même procédure (le même
| scope de la variable)
|
|
| Private Sub Command1_Click()
| Dim REP As String
|
| Do
|
| REP = InputBox("chosissez un nombre à 3 chiffres, sauf 000")
| If REP = "000" Then
| Dim Message As String
| Message = "J'avais dit pas 000, recommencez !"
| MsgBox Message
| ElseIf REP = "111" Then Exit Do
| End If
| Loop
| End Sub

LE TROLL wrote:

Bonjour,

Hello,

Je crois que, quand tu déclares deux fois une variable de même
nom, là il plante, mais ici, à chaque fois qu'il passe sur Dim il
réserve la variable et l'initialise avec ce que le hasard met dedans,

Non.

c'est en fait, non pas comme si tu écrivais plusieurs fois son nom,
mais comme si tu l'initialisais ?

Non plus.

Pour l'InputBox, pas bon, on ne peux plus sortir en abandonnant la
saisie (If REP = "" Then Exit Sub)...

Non, c'est totalement inexact.


Regarde le programme suivant:

Private Sub Command1_Click()

Do While True
Dim s As String
Dim n As Integer
Dim i As Integer

For i = 1 To 3
If n = 0 Then
s = "coucou"
End If
Next i

Debug.Print n, s, i

n = n + 1
If n = 3 Then
Exit Do
End If
Loop
End Sub

L'exécution de ce programme donne:
0 coucou 4
1 coucou 4
2 coucou 4

C'est bien le résultat attendu.

Exécute le en pas à pas et tu comprendras comment ça marche.

Bon week-end.

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr

Jean-marc a écrit :

PH wrote:

jean saint jalmes a écrit :

Hello,

J'imaginais qu'il ne fallait cependant faire attention à ne pas
déclarer de variables dans des boucles (do ... loop, while ... wend,
for ... next) même à l'intérieur d'un if then else
J'imaginais un système dans lequel la plupart du temps on ne repassait
pas sur le dim et qu'exceptionnellemnt on passait deux fois dessus
déclenchant l'erreur "variable déjà déclarée"

Quelle ne fut pas ma surprise de voir que cela fonctionnait sans
problème. Quelqu'un a-t'il une explication ?

Bien sur :-)

Tu oublies que VB est compilé, pas interprété.
Lors de la compilation, le compilateur analyse le code
source et génère le code final.

Quand il va voir, un Dim, il va en tenir compte et générer le code
nécessaire
pour réserver de la place pour cette variable dans le code d'init de la
procédure.
Puis il va générer le reste du code utilisant cette variable.
Et c'est tout :-)
L'exécution du programme résultant de ton code source n'a rien à voir avec
le dit code source: c'est tout l'intérêt d'un compilateur.

Note que même le plus minable des interpréteurs saurait aussi gérer ça de
façon
naturelle: il suffit qu'il ait une règle disant : Dans un contexte donné (la
procédure
par exemple, un Dim n'est effectivement exécuté qu'une seule fois).

Cordialement;

En effet j'aurai du me douter de cela puisque en pas à pas on ne passe
jamais par ces lignes comportant un dim. Par contre le compilateur ne
veut pas qu'il y ait explicitement deux déclarations de la même variable
dans la même procédure. Dans mon cas le doublon n'est pas explicite mais
implicite.

Bon week-end à tous.