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

[David Anton]

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.

[snarfblam]

Be aware that with VB 'For' loops the ending condition is only checked on entry to the loop' date=' while C# 'for' loops check the condition on every iteration[/quote']

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.

 

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

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.

[David Anton]

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' date=' 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? [/quote']

 

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).

Edited August 8, 2006 by David Anton

[snarfblam]

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.

[PlausiblyDamp]

Split from http://www.xtremedotnettalk.com/showthread.php?t=97057 to keep the original threads intention intact.

 

Nothing wrong with a bit of discussion though so I'll leave these comments here.

Edited August 9, 2006 by PlausiblyDamp

[mskeel]

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?

[Mike_R]

Nice list guys :)

 

Building on Cags' inheritance post above' date=' there is a distinction in VB between implementing an interface and inheriting from a class, but there is not in C#.[/quote'] 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?

[snarfblam]

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.

[Mike_R]

Wow, very nice description, Marble. A very neat way of looking at it.

 

Thank you. :)

[David Anton]

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]

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.

[snarfblam]

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.