Do functions return values as byref or byval or?

Hi again
i have a strange issue today. Sample code is at the below of the post. The code that i have pointed out is too strange. According to my knowledge using return statement the functions return values as byval and copies the value to the stack. Also how can my class can reach outscope elements and change them. Take a look at to the code below. How this could be?

code Code:

Public Class Form1
    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim b As New ByteClass
        Dim sumArray As Long = 0
        Dim ByteArray As Byte() = {}
        Dim idx As Integer = 0
        ByteArray = b.GetArray
        sumArray = SumByteArray(ByteArray)
        Do
            idx += 1
            If sumArray <> SumByteArray(ByteArray) Then Exit Do
            Debug.Print("Not changed yet" + "" + Str(idx))
        Loop
        MsgBox("The ByteArray has changed???")
    End Sub
 
    Public Function SumByteArray(ByVal pByteArray As Byte()) As Long
        'This function return the sum value of the ByteArray
        Dim retval As Long = 0
        For i As Integer = 0 To pByteArray.Length - 1
            retval = retval + pByteArray(i)
        Next
        Return retval
    End Function
End Class
Class ByteClass
    Dim ByteArray As Byte() = {}
    Dim Foo As System.Threading.Thread
    Sub New()
        ByteArray = New Byte(4096) {}
        Foo = New System.Threading.Thread(AddressOf ThreadWork)
        Foo.Start()
    End Sub
    Public Function GetArray() As Byte()
        Return ByteArray
    End Function
    Sub ThreadWork()
        'Generate a random mutation on bytestream
        Dim r1 As New Random
        Dim r2 As New Random
        Dim idx As Integer
        Dim v As Integer = 0
        Do
            v = r1.Next(0, 255 + 1)
            idx = r2.Next(0, 4096 + 1)
            ByteArray(idx) = v
            Application.DoEvents()
        Loop
    End Sub
End Class

They don't return ByVal or ByRef, but it would be closest to think of them as returning ByVal. You just have to remember what that means. If you are returning a reference type, you still aren't getting the value, you are getting the address in memory of the actual object, and that's all you are getting. Therefore, if you return a value type like an Integer, you get an integer (the value). If you return a reference type, you are really getting the address of the object. That can trip people up. Exactly what is going on with you code I don't know, as you haven't said what it is doing that you didn't expect. I do notice that you are doing something wrong with the Random objects, but that would be different.

You create two new Random objects back to back. When the object is created, it is seeded with the current system time. Creating two back to back, as you are doing, will cause both to be seeded with the same time unless the time increased between the two objects being created, which is very unlikely. That would mean that the two objects would return the exact same sequence of numbers. Therefore, idx will equal v in virtually every case.

Returns I wouldn't really think of in that manner. Once the function ends, anything created in it goes out of scope and is garbage collected. ByRef is just a means to pass in a reference to a non-object variable (primitive data type), basically VBs dirty little way around using pointers.

Not so dirty. What VB is doing is avoiding using the term 'pointer'. Any reference type only holds a pointer. Passing a value type ByRef passes a pointer to the value type. Passing a reference type ByRef passes a pointer to a pointer. Passing a value type ByVal passes in the actual value. Passing a reference type ByVal passes the contents of the variable, which happens to be just a pointer, so it means effectively passing a pointer. It's a consistent pattern.

Quote:

---

Originally Posted by Shaggy Hiker

Not so dirty. What VB is doing is avoiding using the term 'pointer'. Any reference type only holds a pointer. Passing a value type ByRef passes a pointer to the value type. Passing a reference type ByRef passes a pointer to a pointer. Passing a value type ByVal passes in the actual value. Passing a reference type ByVal passes the contents of the variable, which happens to be just a pointer, so it means effectively passing a pointer. It's a consistent pattern.

---

I meant dirty in that it was a way to fudge in pointer functionality without actual having to deal with them.

Yeah. Pointers cause people lots of confusion. VB has always tried hard to keep that detail away from the users, but they haven't been entirely successful, since there are plenty of questions about that on this forum.

No, references aren't pointers. They can reference and dereference in the same manner, but they are not addresses in memory, so you cannot manipulate them as you would pointers. You cannot increment or decrement the address and thus point to other things in memory. You cannot point it to an arbitrary piece of memory. It can only ever refer to an object of the type that it is a reference to, or to null (Nothing in VB).

Thinking of them in terms of pointers is only helpful if you only ever used pointers for referencing/dereferencing.

They are fundamentally addresses, and might as well be thought of that way in VB. The fact that you can't perform pointer arithmetic on them doesn't change that fact as far as VB is concerned, since you can't perform pointer arithmetic on any other type, either. They are not pointers, but pointers are not solely addresses, either, in most languages.

Quote:

---

Originally Posted by Shaggy Hiker

They are fundamentally addresses

---

No, they are fundamentally references to objects. When have you ever seen a memory address in VB.Net? The only type you will ever come near to encountering such a thing is when you need to interface with unmanaged memory and even then it is limited to possibly telling the GC to pin some memory in place and then getting a reference to an IntPtr object.

Quote:

---

Originally Posted by Shaggy Hiker

and might as well be thought of that way in VB.

---

Why introduce a more complicated and incorrect programming model? The idea of a reference is very simple. It refers to an instance of its reference type or it refers to Nothing.

And this would be a perfect time to point out that ByRef isn't passing a reference to a value or a reference to a reference to an object. If that was the case then you'd need to a) extend the idea of a reference to be able to point to value types and b) handle the double-dereferencing needed to access an object.

What you need to grok is that in .NET a variable is simply a name for a storage location that can hold a value or a reference. (Note: again, no mention of memory addresses). When you pass ByRef you create an alias to an existing storage location instead of creating a new one. It is conceptually similar to a reference, but also fundamentally different. (And confusingly named!)

Now, note that this works both ways (both into and out of methods). The .NET CLR allows for "ref aliases to variables" to be returned from methods. C# and Visual Basic don't support this, however. (That is, the OP's statement regarding return values as ByVal is actually spot-on, but irrelevant).

Quote:

---

Originally Posted by Evil_Giraffe

No, they are fundamentally references to objects.

---

So, you're saying that references don't use pointers under the hood?

No, not at all. That is an implementation detail that is invisible to programmers [EDIT: Assuming that that is, actually, how they work under the hood. It's not going to be as simple as just that, since the memory manager is free to move memory around where it sees fit whilst the process is still using that memory, meaning the addresses will be subject to change at any time], however, so is completely irrelevant. I'm talking about their defined and observable behaviour.


("Fundamental" <> "How they work under the hood")

Quote:

---

Originally Posted by Evil_Giraffe

("Fundamental" <> "How they work under the hood")

---

That depends on how you define fundamental. I think of a reference as a tarted-up pointer, obviously Shaggy does and many others do too. A class instance is stored on the managed heap and a reference must, somewhere in its implementation, contain a pointer to that object. A variable is stored on the stack and that memory location on the stack is either going to contain a value or a memory address. That seems fairly fundamental to me.

You're not incorrect in what you say but Shaggy's point of view is still valid also. Perhaps Shaggy could have worded things slightly better but I know, and I hope you know, that he isn't say that a reference and a pointer are the same thing. He's saying that a reference behaves, in many ways, like a pointer because a reference has a pointer at its heart. We all know that .NET and VB in particular abstracts a lot away but that doesn't mean that the low-level stuff is not still going on.

If anything, a reference is a tarted-down pointer that makes it a lot safer to use. I have no problem with experienced programmers approaching .NET and having a mental model of references in terms of pointers. It's incorrect and misses a lot of the subtleties, but as a private mental model, I'll assume you're competent enough to deal with it quietly by yourself when the analogy fails, and not come running to me (assuming you were on the same team as me) with your broken code.

When explaining the concept, however, it makes no sense to tell beginning programmers that a reference is "just like a pointer except...", because you're either a) overwhelming them with the concept of pointers and then telling them to ignore 90&#37; of the hard stuff and then giving them exceptions where references behave differently to pointers or b) giving them a gimped idea of what a pointer is to make it fit better with the idea of a reference. Why not just explain what a reference is?

A reference is not a pointer. Explain it as its own concept, because it is its own concept.

Isn't this a pointless question "Do functions return values as byref or byval?" ... I mean it is the object so byval would be closer ... but isn't it irrelevant if it is some kind of clone or the original object - because you can't return something edit it then re-go back to it in the function that created it and do something else.. if that makes sense?

Kris

Quote:

---

Originally Posted by jmcilhinney

A class instance is stored on the managed heap and a reference must, somewhere in its implementation, contain a pointer to that object. A variable is stored on the stack and that memory location on the stack is either going to contain a value or a memory address. That seems fairly fundamental to me.

---

That's actually (not quite) how the implementation of the CLR you're currently using works under the covers. As a programmer you never see that.

Explanation of the "not quite" remark:
Certainly, variables do not necessarily live on the stack. A field in a class is a variable that is laid out in the memory area of the instance. You've just said instances are on the heap, so that vairiable must be on the heap. A variable might be enregistered by the JIT optimiser, meaning it stays in the registers and doesn't even get as far as the stack. A variable that is closed over in a lambda expression will get hoisted on to the heap, etc...

And the only reason that objects are stored on the heap is because it is too expensive to do the analysis that would determine if they were visible outside the local scope. If they aren't and there is sufficient room, you could put them on the stack and have the memory freed up as the stack unwinds (that is why the current MS implementation puts local variables that it can verify don't live outside the current scope onto the stack - Garbage Collection is expensive, so avoiding it if you can is a Good Thing(TM)).

Ultimately, things like the stack and the heap are not part of the .NET programming model - they're an implementation detail of the runtime.

Quote:

---

Originally Posted by i00

Isn't this a pointless question "Do functions return values as byref or byval?" ... I mean it is the object so byval would be closer ... but isn't it irrelevant if it is some kind of clone or the original object - because you can't return something edit it then re-go back to it in the function that created it and do something else.. if that makes sense?

---

As I mentioned earlier, the .NET CLR allows for "ByRef" returns from functions. Theoretically, it would be possible to have a future version of VB that supported this. Then you could imagine the following function:

Code:

---

Public Function ByRef Max(ByRef x As Integer, ByRef y As Integer) As Integer
    If x > y
        Return ByRef x
    Else
        Return ByRef y
    End If
End Function

---

Unlike the standard Max function, this does not return the value that is greater, this returns the variable that is greater, which could be further modified:

Code:

---

Dim a As Integer = 123
Dim b As Integer = 456

Dim ByRef c As Integer = Max(a, b)
c = c + 100
Console.WriteLine(b) ' 556!

---

Currently you don't need to declare ByRef at the call site when calling a function with ByRef parameters (unlike in C# which requires 'ref' at both the declaration and the call site), so it is less useful as a big red flag that something weird is going on with your variables.

The equivalent to the above for C# was actually coded as a proof-of-concept, so it's not completely hypothetical, but the usefulness of such a feature is dwarfed by the complexity it adds to the language and the testing required. (The CLR would also need to be updated to be able to verify such ByRef returns, currently they are marked unverifiable)

Quote:

---

Originally Posted by Evil_Giraffe

No, they are fundamentally references to objects.

---

Who does that mean anything to? Frankly, coming from a background in science, reference doesn't mean all that much to me in this context. I'd have a hard time saying something like that and expecting my audience to understand what I meant. An address means something to pretty much any audience. We all learn our addresses from an early age. We learn that we are not our address, but we reside at our address. Our address is a means to locate us. Since the purpose of writing is to communicate, why would we use an abstract term such as 'reference to object', which means nothing to the average person, in place of 'address in memory' which leverages the concept of an address that each of us learns from an early age.

A pointer started out as another name for an address used in programming. It was initially nothing more than the address. There were problems with that simple type of a pointer, so as languages advanced, the concept of a pointer was replaced by the concept of a smart pointer of one flavor or another. But that's pretty esoteric for the average person, and irrelevant to VB. What remains relevant is the concept of an address in memory, and the initial meaning of a pointer. The word still communicates better than reference ever will. We have a hard enough time with communication without making use of what little shared knowledge we all have. What the thing actually is doesn't matter in VB. Nice to know, but not essential to understanding the concept of an object residing at some point in memory, and a reference type variable holding the address of that point in memory.

I think everyone is trying to answer the wrong question. The original question is a bit unclear due to (probably) English being a secondary language. I can't interpret the question at all. So it would have been smarter to ask for clarification. algea, could you try asking the question again? I'm not clear on what you are asking because you didn't explain what you expect to happen vs. what really happens.

Lists keep me brief.

• I don't know the right answer to the question because I do not understand the question.
• We seem to have guessed the question is, "What happens when you return a value?"
• The answer to that question is, "You get reference semantics for reference types and value semantics for value types." That reads as, "You get the same object for reference types and a copy for value types."
• Value semantics vs. reference semantics are important. Pointer semantics vs. reference semantics have no bearing on .NET.

If a child asks, "Why is the sky blue?" you shouldn't respond with a thesis on light's properties in a particle system. The purpose of a memory manager is so you don't have to have these arguments. .NET has two kinds of variable: reference type and value type. Reference type variables are never copied*, and always passed by reference. Value type variables are copied when passed by value, and when passed by reference you get reference semantics. It doesn't matter if they are boxed, if a pointer is passed, or if a reference is passed: there is no dereferencing mechanism so it just happens and that is all the programmer needs to know.

The *one* exception is the case where for whatever reason you need to pass a .NET object to unmanaged code. That's a very advanced use case that will rarely be encountered, and it's not worth adding it as an appendix to, "Do I get the same object when a variable is returned?"

* Particularly nitpicky readers will note there is a situation where reference types are always copied. It is about as appropriate to this discussion as a toaster in a bathtub. You get one gold star and a severe beating with the cluestick for missing the point.

Hi
if you take a look at the code again my problem is too obvious so i don't need so much explanation inside Semantic such that i am both trying to improve my Language knowledge so i prefer or dare to ask inside foreign forum.
I have invented this by mistake while studying on a different kind of project and i have tried to give inside another abstract explanation
i have confused by the results only.
There is also a solution for this using clone method...
But then it will cause optimization problem also because the cluster block that i am trying to manage is two big and after iterations stoling from CPU time
if you are trying say that return returns values as byref then there is no need to argue but i remember different...
Thanks all

I think I was the primary culprit for dragging this discussion off in the wrong direction. I think I now agree with what Sitten has stated: I don't understand the question.

You stated:

Quote:

---

Also how can my class can reach outscope elements and change them.

---

This is a question, but of what sort? Are you seeing your class reaching elements that are out of scope and changing them? If that is correct, where are you seeing that in the code you posted? Or are you asking HOW your class would be able to reach elements that are out of scope?

I made some changes to the original code to help me maybe understand the question. I think (watch out) that the OP is questioning the relationship between Dim ByteArray As Byte() = {} and Dim bcByteArray As Byte() = {} (note: I renamed the array inside of ByteClass to alleviate confusion):

Code:

---

Public Class Form1

    Private Sub Button1_Click(sender As System.Object, _
                              e As System.EventArgs) Handles Button1.Click
        Dim b As New ByteClass
        Dim sumArray As Long = 0
        Dim ByteArray As Byte() = {}
        Dim idx As Integer = 0
        ByteArray = b.GetArray
        'ByteArray and b.ByteArray are the same thing
        Stop
        sumArray = SumByteArray(ByteArray)
        Do
            idx += 1
            If sumArray <> SumByteArray(ByteArray) Then Exit Do
            Debug.Print("Not changed yet" + "" + Str(idx))
        Loop
        MsgBox("The ByteArray has changed???")
    End Sub

    Public Function SumByteArray(ByVal pByteArray As Byte()) As Long
        'This function return the sum value of the ByteArray
        Dim retval As Long = 0
        For i As Integer = 0 To pByteArray.Length - 1
            retval = retval + pByteArray(i)
        Next
        Return retval
    End Function
End Class

Class ByteClass
    Const magicNum As Integer = 8
    Dim bcByteArray As Byte() = {}
    Dim Foo As System.Threading.Thread
    Shared PRNG As New Random

    Sub New()
        bcByteArray = New Byte(magicNum - 1) {}
        Foo = New System.Threading.Thread(AddressOf ThreadWork)
        Foo.IsBackground = True
        Foo.Start()
    End Sub

    Public Function GetArray() As Byte()
        Return bcByteArray
    End Function

    Sub ThreadWork()
        'Generate a random mutation on bytestream
        Threading.Thread.Sleep(1000)
        Dim idx As Integer
        Dim v As Integer = 0
        Do
            v = PRNG.Next(0, Byte.MaxValue + 1)
            idx = PRNG.Next(0, magicNum)
            bcByteArray(idx) = CByte(v)
            Threading.Thread.Sleep(0) 'give up the processor
        Loop
    End Sub
End Class

---

out of concept:
if this MagicNum really works or not inside blockings till to the basic's alternates.