If I want to narrow scope of a variable in C#, I can introduce additional braces - i.e.:
class Program
{
static void Main(string[] args)
{
myClass x = new myClass();
x.MyProperty = 1000;
Console.WriteLine("x = " + x.MyProperty);
{
myClass y = new myClass();
y.MyProperty = 2000;
Console.WriteLine("y = " + y.MyProperty);
}
myClass y2 = new myClass();
y2.MyProperty = 3000;
Console.WriteLine("y2 = " + y2.MyProperty);
}
class myClass
{
public int MyProperty { get; set; }
}
}
In the ide, I can no longer reference y outside of the scope introduced by the new braces. I would have thought that this would mean that the variable y would be available for garbage collection.
(it is interesting to note that when viewing the compiled code using reflector it appears that there is no difference with or without the additional braces)
Is there any way similar to this to narrow scope when using VB.net? Does this have any impact on when variables defined in the inner scope may be garbage collected?
Interestingly, the developerFusion c#-vb.net code converter converts
{
myClass y = new myClass();
y.MyProperty = 2000;
Console.WriteLine("y = " + y.MyProperty);
}
to
If True Then
Dim y As New [myClass]()
y.MyProperty = 2000
Console.WriteLine("y = " & y.MyProperty)
End If
as a way of limiting the scope. I'm surprised it bothers bearing in mind paintballbob's answer
there doesn't seem to be a good way to create a new scope in vb, but you can make a loop that runs only once guaranteed and then declare your variable inside that loop.
MSDN had this to say about the lifetime of a variable:
Even if the scope of a variable is limited to a block, its lifetime is still that of the entire procedure. If you enter the block more than once during the procedure, each block variable retains its previous value. To avoid unexpected results in such a case, it is wise to initialize block variables at the beginning of the block.
src: http://msdn.microsoft.com/en-us/library/1t0wsc67.aspx
it seems that the variables are only subject to garbage collection once the procedure has finished, but even then the garbage collector will not run unless the heap is getting crowded. Most likely for small apps nothing ever gets garbage collected until the app is closed.
In C# at least, it doesn't make any difference to garbage collection when a debugger isn't attached - the GC is able to work out when a variable is last read, and a variable doesn't count as a GC root after that point. For example:
object y = new object();
Console.WriteLine("y is still a GC root");
Console.WriteLine(y);
Console.WriteLine("y is not a GC root now");
y = null;
Console.WriteLine("y is still not a GC root");
(In terms of terminology, the variable itself isn't collected, it's just that while it counts as a "root" to the garbage collector, it prevents the object it's referring to from being collected.)
When you've got a debugger attached, the GC is much more conservative, as you may want to examine a variable's value after its last "normal" read point.
The major benefit to reducing scoping is clarity, IMO. If a variable has a narrow scope, you can forget about it when you're not looking at that bit of code (assuming it's not captured by a delegate etc).
I don't know whether VB has any equivalent of a statement block for no reason other than scoping; the nearest equivalent may be a With statement... or a Do ... Loop While False statement, neither of which is entirely satisfactory.
Why not just create a few methods? A scope should be defined in a method. Once you exit the method you leave the scope - clean and easy. The way you are doing is very unorthodox - I would suggest you stick to convention and use methods if you are worried about scope creep (what you are describing).
