Sub vs. Functions in VB.NET

What's the difference between a sub and a function? If I write a function that doesn't return a value, isn't it just like a sub? Why are both available when a function can do everything itself? Is there any difference at the IL level?

Apex wrote:

What's the difference between a sub and a function? If I write a function that doesn't return a value, isn't it just like a sub? Why are both available when a function can do everything itself? Is there any difference at the IL level?

I guessed it is VB.NET's way of being more elaborative and specific. You have already mentioned the difference, Sub does not return a value (although still can be done) and Function does.

But I'm curious on what you mentioned, can you actually code a function without a return type in VB.NET?

Firedancer wrote:

But I'm curious on what you mentioned, can you actually code a function without a return type in VB.NET?

 Yes. It will return Object if no type is specified.
I think in the older days of VB, if no type is specified, Variant is assumed to be the default?

Function FuncNoRetType()
   Return 10
End Function

Corresponding IL code
.method public static object  FuncNoRetType() cil managed
{
  .maxstack  1
  .locals init ([0] object FuncNoRetType)
  IL_0000:  nop
  IL_0001:  ldc.i4.s   10
  IL_0003:  box        [mscorlib]System.Int32
  IL_0008:  stloc.0
  IL_0009:  br.s       IL_000b
  IL_000b:  ldloc.0
  IL_000c:  ret
}Notice the boxing of 10 to a Int32.

But if

Function FuncNoRetType()
  ' do nothing
End Function

.method public static object  FuncNoRetType() cil managed
{
  .maxstack  1
  .locals init ([0] object FuncNoRetType)
  IL_0000:  nop
  IL_0001:  ldloc.0
  IL_0002:  ret
}

As far as I can remember, there is also a preformance difference between a sub and a function...

Wouldn't matter much in the performance difference nowadays, with all those super fast servers out there.

all those.. yes...
But, not all...
Anyways, in critical sitiation it might make a difference...

VB.net is not always used for programming web or win app... dun forget you still got compact framework, which runs a bit slower...

Performance will be better while using sub compared to function.

 

Public Function NoReturnFunVB()

End Function

.method public instance object  NoReturnFunVB() cil managed
{
  // Code size       3 (0x3)
  .maxstack  1
  .locals init ([0] object NoReturnFunVB)
  IL_0000:  nop
  IL_0001:  ldloc.0
  IL_0002:  ret
} // end of method Class1::NoReturnFunVB

 

Public Sub NoReturnSubVB()

End Sub

.method public instance void  NoReturnSubVB() cil managed
{
  // Code size       3 (0x3)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  nop
  IL_0002:  ret
} // end of method Class1::NoReturnSubVB

 

public void NoReturnCSharp()

{

}

.method public hidebysig instance void  NoReturnCSharp() cil managed
{
  // Code size       2 (0x2)
  .maxstack  0
  IL_0000:  nop
  IL_0001:  ret
} // end of method Class1::NoReturnCSharp

Look at these MSIL instructions, C# has the cleanest implementation of a void method; the size of the evaluation stack is 0 and there is nothing except a mandatory nop, followed by return.

VB.NET sub is next, but mysteriously it has a .maxstack 8 statement at the top, what are they thinking?? Although that does not mean the run time evaluation stack is 8, the statement is used only for static analyzer by the verifier during the assembly loading phase.

VB.NET function with no explicit return type is the ugliest. To preserve genericity, the all mighty object is used as the base type so that even if you return an arraylist of arraylists of arraylists of... is fine.