How come this doesn't cause an endless loop?

  • Thread starter Thread starter Lucvdv
  • Start date Start date
L

Lucvdv

VS2005: can someone explain why this code doesn't cause endless recursion?
It just returns False.

However, if you replace "Return TestProp" with "Return Me.TestProp", the
compiler warns for recursion (a warning, not an error), and it fails with a
stack overflow at runtime -- as expected.


Public Class Form1

Private Class TestClass
Public ReadOnly Property TestProp() As Boolean
Get
Return TestProp
End Get
End Property
End Class

Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs _
) Handles MyBase.Load
Dim t As New TestClass
Debug.WriteLine(t.TestProp)
End Sub

End Class
 
VB weirdness...
Seriously though, the reason is that VB still allows using the method or
property name as a temp variable. In this case, "TestProp" is VB's
non-declared local variable that holds the eventual return value of the
property. Usually, standards would dictate that you avoid this legacy VB
hack, but you can still cause a method to return this by coding "MethodName =
SomeValue". I have never seen it used in an actual 'Return' statement before
- this is very creative of you.
i.e., what you've done is equivalent to:
Public ReadOnly Property TestProp() As Boolean
Get
Exit Property 'return the implicit variable "TestProp"
End Get
End Property
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
C++ to C# Converter: converts C++ to C#
Instant C++: converts C# or VB to C++/CLI
 
Lucvdv said:
VS2005: can someone explain why this code doesn't cause endless recursion?
It just returns False.

However, if you replace "Return TestProp" with "Return Me.TestProp", the
compiler warns for recursion (a warning, not an error), and it fails with
a
stack overflow at runtime -- as expected.


Public Class Form1

Private Class TestClass
Public ReadOnly Property TestProp() As Boolean
Get
Return TestProp
End Get
End Property
End Class

Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs _
) Handles MyBase.Load
Dim t As New TestClass
Debug.WriteLine(t.TestProp)
End Sub

End Class
Click to expand...

What are your options for the project or class. If you are not option
explicit then the compiler will create variables for items you have not
declared. In your example you did not declare TestProp so it creates one.
As you noticed when you use me.TestProp it then knew that a property with
that name exists and then gives you an error.

The best way to avoid this is to always uses option exlicit and usually
option strict. Otherwise you will keep having errors that are difficult to
debug.

Lloyd Sheen
 
The code compiles with Option Explicit turned on.
It's just the implicit method name variable that VB creates whether you use
it or not.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
C++ to C# Converter: converts C++ to C#
Instant C++: converts C# or VB to C++/CLI
 
The very first thing any VB .NET developer should do with VS.NET is set
Option Strict On in Tools...Options. It makes the language type-safe like
C# and prevents many errors that wouldn't get caught until runtime.
 
But this isn't the problem here - the problem is accidently refering to VB's
archaic hidden return value variable.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
C++ to C# Converter: converts C++ to C#
Instant C++: converts C# or VB to C++/CLI
 
I know, I'm responding (or adding to) the last reply, which discussed Option
Strict.
 
The best way to avoid this is to always uses option exlicit and usually
option strict. Otherwise you will keep having errors that are difficult to
debug.
Click to expand...

[Sorry for the late reply]

I always have option explicit on.

In large or complicated projects I also set option strict on, but AFAIR I
don't think that was the case here.



Looks like a couple of bugs then:

1) This sample SHOULD have generated an error because of Option Explicit,
but it didn't.

2) The tooltip displayed when you hover the mouse over TestProp (the
variable) shows it as the property, not a local variable.




Just BTW: I discovered it when I forgot a prefix.

I often call a member variable 'm_prop' if it's used to keep the value of a
property 'prop'. Here I forgot the m_ prefix. It compiled, but it didn't
work :)

Now I'm beginning to think my 'm_' prefixes aren't such a good idea, too
easy to forget.
 
Inline comments....

Lucvdv said:
The best way to avoid this is to always uses option exlicit and usually
option strict. Otherwise you will keep having errors that are difficult
to
debug.
Click to expand...

[Sorry for the late reply]

I always have option explicit on.
Click to expand...

Visual Studio ships with Option Explicit On and you should NEVER change it.
In large or complicated projects I also set option strict on, but AFAIR I
don't think that was the case here.
Click to expand...

You should turn Option Strict On and leave it on for good. Having it off
only leads to mysterious runtime errors and poor performance.
Just BTW: I discovered it when I forgot a prefix.

I often call a member variable 'm_prop' if it's used to keep the value of
a
property 'prop'. Here I forgot the m_ prefix. It compiled, but it didn't
work :)

Now I'm beginning to think my 'm_' prefixes aren't such a good idea, too
easy to forget.
Click to expand...

I use just "m" on my local member variables myself (as do many others), it's
not a bad habit at all. You just need to remember to use it. That's the
great thing about standards and best practices, if you use them
consistently, you won't forget to use them.
 
Back
Top