What are the things to consider when choosing between ByRef and ByVal.
I understand the difference between the two but I don't fully understand if ByRef saves resources or if we even need to worry about that in the .Net environment.
How do you decide between the two if the functionality doesn't matter in a situation?
There's a lot of misinformation around about this. The main thing is that you understand the difference between value types and reference types, and the difference between pass by value and pass by reference.
You almost always want to pass by value. Passing by reference is almost always for "I want to return more than one result, and not just by adding things to a list which is passed in." The classic example of a method using pass-by-reference is Int32.TryParse where the return value is a success/failure, and the parsed value is "returned" by an out parameter.
The default is byValue for ALL types, but it is important to understand what the two options mean for a "reference type" (a class) as opposed to a value type. (structs).
For a reference type, if you declare a reference type variable in a method, that variable is a memory location in the stack frame of the method. It is not on the heap. When you initialize that variable (using new or a factory, whatever), then you have created an actual object on the heap, and the address of that object is stored in the declared reference variable in your methods stack frame.
When you pass a reference type to another method byVal, you are creating a copy of the address stored in the calling methods stack and passing the copy of that value (the pointer address) to the called method, where it is stored in a new memory slot in the called methods stack. Inside the called method, the new cloned variable points directly to the same object on the Heap. So using it can change the properties of the same object. But you cannot change which heap object the original reference variable (on the calling methods stack) points to. If, in the called method I write
myVar = new object();
The original variable in the calling method will not have changed to point to a new object.
If I pass a reference type byRef, otoh, I am passing a pointer to the declared variable in the calling methods stack (which contains a pointer to the object on the heap) It is therefore a pointer to a pointer to the object. It points to the memory location on the calling methods stack, which points to the object on the heap.
So now, if I change the value of the variable in the called method, by setting it to a new object(), as above, since it is a "refereence" to the variable in the calling method, I am actually changing which object the variable in the calling method is pointing to. So After the called method returns, the variable in the calling method will no longer be pointing to the same original object on the heap.
ByVal should be your "default". Use it unless you have a specific reason to use ByRef
Passing an object ByVal in .net does not make a copy of the object and does not consume more resources then ByRef, A pointer is still passed through to the function. The runtime just ensures that you can't modify the pointer in your function and return a different value for it. You can still make changes to the values within the object and you will see those changes outside the function. That is why ByRef is uses so rarely. It is only needed when you want a function to change the actual object that is coming back; hence an output parameter.
Use "ByRef" only if the parameter is "output" parameter. Otherwise use "ByVal". Using "ByRef" on parameters which explicitly should not return values is dangerous and can easy generate bugs.
I would argue that ByRef should never be used--that it's a bad practice. I would apply that even to its typical use case of allowing a function to return multiple values (via ByRef parameters). It would be better for the function to return a structured response that includes those multiple return values. It's more clear and more obvious if a function only returns values via its return statement.
According to Microsoft, choosing ByVal or ByRef can affect performance for large enough values (see Passing Arguments by Value and by Reference (Visual Basic)):
Performance. Although the passing mechanism can affect the performance of your code, the difference is usually insignificant. One exception to this is a value type passed ByVal. In this case, Visual Basic copies the entire data contents of the argument. Therefore, for a large value type such as a structure, it can be more efficient to pass it ByRef.
[emphasis added].
Sub last_column_process()
Dim last_column As Integer
last_column = 234
MsgBox last_column
trying_byref x:=last_column
MsgBox last_column
trying_byval v:=last_column
MsgBox last_column
End Sub
Sub trying_byref(ByRef x)
x = 345
End Sub
Sub trying_byval(ByRef v)
v = 555
End Sub
Marking certain arguments as ByRef shows the user of your function that the variable allocated to that argument **will be modified.****
If you use ByRef for all args, there'll be no way to tell which variables are modified by the function, and which are just read by it. (apart from peeking inside the function source!)
Lots of confusion I will try to simplify. You basically have 4 choices:
Some people say you should never use byRef. While they are technically correct, one thing is for certain. You should NEVER use the word never. If you are designing a system from scratch then byRef should be avoided at all costs. Using it exposes a design flaw. However working on an existing system may not provide as much flexability to implement a good design. Sometimes you must make consessions, i.e. using byRef. For example if you can get a fix in done in 2 days using byRef then that can be preferable to re-inventing the wheel and taking a week to get the same fix in just to avoid using byRef.
Summary:
