Split from - C# to/from VB.Net Recipes

David Anton

Newcomer
Joined
Apr 12, 2006
Messages
21
Be aware that with VB 'For' loops the ending condition is only checked on entry to the loop, while C# 'for' loops check the condition on every iteration (unless the JIT compiler decides that the ending condition never changes between iterations).

Also, only the simplest C# 'for' loops can be converted to VB 'For' loops. The rest must be converted to 'Do While' loops in VB.
 
David Anton said:
Be aware that with VB 'For' loops the ending condition is only checked on entry to the loop, while C# 'for' loops check the condition on every iteration
I don't understand what you are saying. You post reads as though a VB for loop is checked for a terminating situation prior to any iterations of the loop and then never again, which obviously isn't the case. Are you saying that the terminating value is calculated only once prior to any iterations in a VB for loop and that the terminating expression is evaluated each iteration in a C# for loop?

If so, then good point.

Visual Basic:
Module Module1
 
    Sub Main()
        For i As Integer = 0 To Get5()
            Console.WriteLine(i.ToString())
        Next
        Console.ReadLine()
    End Sub
 
    Public Function Get5() As Integer
        Console.WriteLine("5")
        Return 5
    End Function
End Module
C#:
using System;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main() {
            for(int i = 0; i < Get5(); i++) {
                Console.WriteLine(i.ToString());
            }
            Console.ReadLine();
        }

        static int Get5() {
            Console.WriteLine("5");
            return 5;
        }
    }
}
The two code seemingly identical code listings, when run as console applications, demonstrate the difference.
 
marble_eater said:
I don't understand what you are saying. You post reads as though a VB for loop is checked for a terminating situation prior to any iterations of the loop and then never again, which obviously isn't the case. Are you saying that the terminating value is calculated only once prior to any iterations in a VB for loop and that the terminating expression is evaluated each iteration in a C# for loop?

Yes - the latter is what I was saying - I can see how my choice of words was poor. In VB the terminating value is calculated just once while in C# it is calcuated on every iteration if the compiler determines that the terminating value may change (e.g., a value that is changed during the loop).
 
Last edited:
Maybe a mod can clean up my post, the one before, the one after, and this one. This isn't really the thread to have a conversation lumped in the middle of.
 
This is good discussion, thanks for splitting it out.

I didn't realize there was the subtle difference but I still think that it is unwise to be changing your loop terminating conditions while within the loop (maybe I never noticed because I never flexed it?). I believe it's even forbidden from with a foreach loop (for example, iterating through a list and removing items as you go). They are called loop invariants because they don't vary while executing your loop. Once the condition is met, you terminate the loop and that's it -- it's not keep looping until it's 5, no wait 10, no wait 15 , ...

In this situation, you can never prove that your loop will terminate for all conditions and that's not a great situation to be in. One check should be more than enough or you should think about using a different type of loop or invariant.

Now in terms of performance...this might cause an issue and is nice to know, especially if you are calling a function to get a value for comparison every iteration...but I assumed this would be optimized by the compiler?
 
Nice list guys :)

mskeel said:
Building on Cags' inheritance post above, there is a distinction in VB between implementing an interface and inheriting from a class, but there is not in C#.
This is something that has definately confused me. I'm not normally a C# coder, but I can read it pretty ok... But implimenting an interface and inheriting a class is definately not the same thing, and yet, C# does not seem to distinguish...

Can someone clarify this? Is the only way to tell is to look at the code therein? If a class implements ISomeInterface and inherits SomeBaseClass, is there a convention that the 'SomeBaseClass' should be listed first? Or is the naming convention that interfaces begin with an "I" the only real clue?
 
Syntactically speaking, there is no distinction. The "I" is your biggest clue. Besides that, the base class, if there is one, must be the first in the list. This means that the first item in the inheritance list could be a base class or an interface. Every other one will be an interface.

The difference in syntax is the result of a difference in point of view. In a manner of speaking (and as represented in IL), an interface is an abstract class that contains only abstract methods and properties, and in a manner of speaking, you are inheriting each of the interfaces you implement. Your class does inherit all of their functions. An interface is kind of like an abstract class that is very restrictive for the sake of allowing multiple inheritance. If you can see it that way, the syntax suddenly seems much more intuitive.
 
The last VB example should be:
Class HasDefaultConstructor(Of T As {SomeBaseClass, IEnumerable, New})

instead of:
Class HasDefaultConstructor(Of T As New, SomeBaseClass, IEnumerable)
 
David Anton said:
The last VB example should be:
Class HasDefaultConstructor(Of T As {SomeBaseClass, IEnumerable, New})

instead of:
Class HasDefaultConstructor(Of T As New, SomeBaseClass, IEnumerable)

Note that they both compile, but they mean different things - the one with the curly braces means the same thing as the C# one.
 
My mistake.

-Multiple constraints on a type argument should be enclosed in curly braces.
-There is no requirement for the order of constraints in VB.

Maybe a mod can fix my post. And delete these last three posts.
 
Back
Top