While (and For) loops with strings

Drak

Say I have the follwoing code:

Sub Main()

Dim intI As Integer = 0
Dim intJ As Integer = 0

While intI < 10

Dim strTest As String
If strTest Is Nothing Then
intJ += 1
strTest = "Been here"
End If
intI += 1

End While

Console.WriteLine(intI & " : " & intJ)
End Sub

What would you expect it to return?

Mike_R

Ummm... 10:10 ....

Drak

Too bad it returns 10 : 1

Yes, a string DIMmed in a while loop seems to be static, and so has a value already if you re-enter the while loop. The value is not removed at the next DIMming.

Didn't someone once post that Dim strString as String = Nothing was bad practice? I think this proves otherwise :P

Drak

Mike_R

Odd. I would have expected that in each iteration in the loop the
string would have been reinitialized to nothing, or an empty, due to
scoping rules. Hm, I guess scope doesn't mean the same thing in VB as
it does in C++. Question is, can you access the string after the while
loop?

Mike_R

Hmm,

Actually, after breaking out VB.NET (a rare occurance...) The program
works as expected if strTest is dimmed as "Dim strTest as String =
Nothing", but doesn't work as expected when strTest is not initialized
in the Dim statement. It was my understanding that Dim automatically
initialized variables at the point they were dimmed.

rsynnott

Apparently VB doesn't do proper scoping, or else treats things defined
in scope as static. Either is weird behaviour. Does it treat function
variables as static by default as well?

Drak

Uhm, function variables are always initialized.

Optional parameters have to be supplied with a default value, so I think you cannot have uninitialized function variables.

Drak

ps. You cannot access the string from outside of the while loop. It wouldn't compile [;)]

Mike_R

An aside:

This simple C program behaves as the above VB program:

int main()

{

 int intI = 0;

 int intJ = 0;

 while(intI < 10)

 {

 int iTst;

 if(iTst != 1)

 intJ+=1;

 iTst = 1;

 intI++;

 }

 printf("%i:%i", intI, intJ);

 return 0;

}

Interestingly, This (less simple, but still simple) C++ program does not:

struct CTest

{

 CTest(int i = 0)

 {

 m_val = i;

 printf("Construct\n");

 }

 ~CTest()

 {

 printf("Destruct\n");

 }

 operator int ()

 {

 return m_val;

 }

 int m_val;

};

int main()

{

 int intI = 0;

 int intJ = 0;

 while(intI < 10)

 {

 CTest iTst;

 if(iTst != 1)

 intJ+=1;

 iTst.m_val = 1;

 intI++;

 }

 printf("%i:%i", intI, intJ);

 return 0;

}

If you run it, you'll see a series of 10 construct/destruct pairs, then the expected output 10:10.

The reason? While both are store on the stack, the CTest object's
constructor gets called at the beginning of the loop, and the
destructor at the end of the loop. If you remove the destructor, it
acts as the VB Program. Of course, the output of uninitialized data is
not defined... This is an artifact of the compiler's stack, the
variable just simple winds up at the same location on the stack every
time. [:D]

Gonzalo

Just a question. Why are u using strTest like an object?

Gonzalo

oh, I see....fucking VB.NET

zinglons_ale

The MSDN library documentation on variable lifetime in VB.NET explains all this.

To quote:

Variables declared within a block inside a procedure are initialized to their default values on entry to the procedure. These initializations take effect whether or not the block is ever executed.

GeneWitch

[quote user="zinglons_ale"]The MSDN library documentation on variable lifetime in VB.NET explains all this.
To quote:

Variables declared within a block inside a procedure are initialized to their default values on entry to the procedure. These initializations take effect whether or not the block is ever executed.
[/quote]
It's fairly simple, scoping rules are a PITA. So Microsoft in their infinite wisdom made sure that while the SCOPE of a variable is limited to it's current block - {} in C++ terms - the instantiation can only happen once. I am pretty sure there is a flag in the visualstudio that will yell at you for trying to redim a dim'd variable - a warning at the very least. This is just so you don't get those silly errors where your data never does what it is supposed to. They want you to do a dim x as integer = 0 to reset. Actually, i wonder if throwing the = 0 at the end will fix the loop you have above, OP? VB.Net does have a lot of perks, such as shallow learning curve and enough power to handle most things, but stuff like this can drive a programmer insane (i.e. you expect the variable to get cleared every time through the loop)
dim myString as String = nothing 'should fix it