• 0

Some curious question about VB.NET


Question

I've always wondered what distinguishes the difference between a sub routine and a Function, obviously a function has the ability to return a value, however in VB it can also act as a sub routine, then if that's the case, what's the need for sub routines then?

Thanks.

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 0
How can you have a function act as a sub-routine? By not returning anything?

584824358[/snapback]

Well in VB.NET you can make a function and not even specify the return type.

Link to comment
Share on other sites

  • 0
Well in VB.NET you can make a function and not even specify the return type.

584827205[/snapback]

In those cases, the compiler makes the function return an Object. It then appends the line Return Nothing to the end.

Link to comment
Share on other sites

  • 0
In those cases, the compiler makes the function return an Object. It then appends the line Return Nothing to the end.

584828043[/snapback]

Yes but still wouldn't that just make Sub routines useless then.

Link to comment
Share on other sites

  • 0

^ :blink: You make my brain hurt. In fact, this whole topic does. What's the point? :wacko: But I am interested, so I must investigate... :shifty:

[/rabmlings]

I made a sample project just to try this. Here's the code, I didn't change anything inside the form designer's code region.

Public Class Form1
 ? ?Inherits System.Windows.Forms.Form

 ? ?Windows Form Designer generated code

 ? ?Public Function blah()

 ? ?End Function
End Class

The above code is compiled into this (in IL, translated back into VB):

Public Function blah() As Object
 ? ? ?Dim obj1 As Object
 ? ? ?Return obj1
End Function

So, it appeares Sn1p3t is half correct. I don't believe you can ever return Nothing, however, since Nothing is the VB equivalent of null, which (to my knowlege) can't be returned by any in any language. Also, a function cannot have a return type of Nothing, or null, because they are not types. The void type is used by subs, and you can't declare a function that returns type void, so that's not an option either. Dayon is also correct in saying that such a function would use slightly more memory (and possibly "slower", depending on how the CLR initiates) by declaring a variable.

Something that I found interesting: the compiled code is nonewg a new object, but just an object, meaning it's never initialized. If the calling method were to perform an operation on the returned object, an exception would be thrown, bringing bugs into the application.

All in all, it's just easier to say that doing this is not a good idea, and there's no real purpose. If you don't intend to return anything, use a sub.

Link to comment
Share on other sites

  • 0

You can have a function act as a sub routine, not specifying the return type at all will turn it into a sub routine e.g.

Function displayMsg()
        MessageBox.Show("Hey")
    End Function

What's more funny is, even if you specify a return type

the compiler doesn't whinge that you didn't return a value:

Function displayMsg() As String
        MessageBox.Show("Hey")
    End Function

Link to comment
Share on other sites

  • 0
You can have a function act as a sub routine, not specifying the return type at all will turn it into a sub routine e.g.

Function displayMsg()
 ? ? ? ?MessageBox.Show("Hey")
 ? ?End Function

What's more funny is, even if you specify a return type

the compiler doesn't whinge that you didn't return a value:

Function displayMsg() As String
 ? ? ? ?MessageBox.Show("Hey")
 ? ?End Function

584830755[/snapback]

It adds the return statemeildasmb>ildasm the compil(Y)assembly (Y)

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.