Related
Consider the following code (I have purposefully written MyPoint to be a reference type for this example)
public class MyPoint
{
public int x;
public int y;
}
It is universally acknowledged (in C# at least) that when you pass by reference, the method contains a reference to the object being manipulated, whereas when you pass by value, the method copies the value being manipulated, thus the value in global scope is not affected.
Example:
void Replace<T>(T a, T b)
{
a = b;
}
int a = 1;
int b = 2;
Replace<int>(a, b);
// a and b remain unaffected in global scope since a and b are value types.
Here is my problem; MyPoint is a reference type, thus I would expect the same operation on Point to replace a with b in global scope.
Example:
MyPoint a = new MyPoint { x = 1, y = 2 };
MyPoint b = new MyPoint { x = 3, y = 4 };
Replace<MyPoint>(a, b);
// a and b remain unaffected in global scope since a and b...ummm!?
I expected a and b to point to the same reference in memory...can someone please clarify where I have gone wrong?
Re: OP's Assertion
It is universally acknowledged (in C# at least) that when you pass by reference, the method contains a reference to the object being manipulated, whereas when you pass by value, the method copies the value being manipulated ...
TL;DR
There's more to it than that. Unless you pass variables with the ref or out keywords, C# passes variables to methods by value, irrespective of whether the variable is a value type or a reference type.
If passed by reference, then the called function may change the variable's address at the call-site (i.e. change the original calling function's variable's assignment).
If a variable is passed by value:
if the called function re-assigns the variable, this change is local to the called function only, and will not affect the original variable in the calling function
however, if changes are made to the variable's fields or properties by the called function, it will depend on whether the variable is a value type or a reference type in order to determine whether the calling function will observe the changes made to this variable.
Since this is all rather complicated, I would recommend avoiding passing by reference if possible (instead, if you need to return multiple values from a function, use a composite class, struct, or Tuples as a return type instead of using the ref or out keywords on parameters)
Also, when passing reference types around, a lot of bugs can be avoided by not changing (mutating) fields and properties of an object passed into a method (for example, use C#'s immutable properties to prevent changes to properties, and strive to assign properties only once, during construction).
In Detail
The problem is that there are two distinct concepts:
Value Types (e.g. int) vs Reference Types (e.g. string, or custom classes)
Passing by Value (default behaviour) vs Passing by Reference(ref, out)
Unless you explicitly pass (any) variable by reference, by using the out or ref keywords, parameters are passed by value in C#, irrespective of whether the variable is a value type or reference type.
When passing value types (such as int, float or structs like DateTime) by value (i.e. without out or ref), the called function gets a copy of the entire value type (via the stack).
Any change to the value type, and any changes to any properties / fields of the copy will be lost when the called function is exited.
However, when passing reference types (e.g. custom classes like your MyPoint class) by value, it is the reference to the same, shared object instance which is copied and passed on the stack.
This means that:
If the passed object has mutable (settable) fields and properties, any changes to those fields or properties of the shared object are permanent (i.e. any changes to x or y are seen by anyone observing the object)
However, during method calls, the reference itself is still copied (passed by value), so if the parameter variable is reassigned, this change is made only to the local copy of the reference, so the change will not be seen by the caller. This is why your code doesn't work as expected
What happens here:
void Replace<T>(T a, T b) // Both a and b are passed by value
{
a = b; // reassignment is localized to method `Replace`
}
for reference types T, means that the local variable (stack) reference to the object a is reassigned to the local stack reference b. This reassign is local to this function only - as soon as scope leaves this function, the re-assignment is lost.
If you really want to replace the caller's references, you'll need to change the signature like so:
void Replace<T>(ref T a, T b) // a is passed by reference
{
a = b; // a is reassigned, and is also visible to the calling function
}
This changes the call to call by reference - in effect we are passing the address of the caller's variable to the function, which then allows the called method to alter the calling method's variable.
However, nowadays:
Passing by reference is generally regarded as a bad idea - instead, we should either pass return data in the return value, and if there is more than one variable to be returned, then use a Tuple or a custom class or struct which contains all such return variables.
Changing ('mutating') a shared value (and even reference) variable in a called method is frowned upon, especially by the Functional Programming community, as this can lead to tricky bugs, especially when using multiple threads. Instead, give preference to immutable variables, or if mutation is required, then consider changing a (potentially deep) copy of the variable. You might find topics around 'pure functions' and 'const correctness' interesting further reading.
Edit
These two diagrams may help with the explanation.
Pass by value (reference types):
In your first instance (Replace<T>(T a,T b)), a and b are passed by value. For reference types, this means the references are copied onto the stack and passed to the called function.
Your initial code (I've called this main) allocates two MyPoint objects on the managed heap (I've called these point1 and point2), and then assigns two local variable references a and b, to reference the points, respectively (the light blue arrows):
MyPoint a = new MyPoint { x = 1, y = 2 }; // point1
MyPoint b = new MyPoint { x = 3, y = 4 }; // point2
The call to Replace<Point>(a, b) then pushes a copy of the two references onto the stack (the red arrows). Method Replace sees these as the two parameters also named a and b, which still point to point1 and point2, respectively (the orange arrows).
The assignment, a = b; then changes the Replace methods' a local variable such that a now points to the same object as referenced by b (i.e. point2). However, note that this change is only to Replace's local (stack) variables, and this change will only affect subsequent code in Replace (the dark blue line). It does NOT affect the calling function's variable references in any way, NOR does this change the point1 and point2 objects on the heap at all.
Pass by reference:
If however we we change the call to Replace<T>(ref T a, T b) and then change main to pass a by reference, i.e. Replace(ref a, b):
As before, two point objects allocated on the heap.
Now, when Replace(ref a, b) is called, while mains reference b (pointing to point2) is still copied during the call, a is now passed by reference, meaning that the "address" to main's a variable is passed to Replace.
Now when the assignment a = b is made ...
It is the the calling function, main's a variable reference which is now updated to reference point2. The change made by the re-assignment to a is now seen by both main and Replace. There are now no references to point1
Changes to (heap allocated) object instances are seen by all code referencing the object
In both scenarios above, no changes were actually made to the heap objects, point1 and point2, it was only local variable references which were passed and re-assigned.
However, if any changes were actually made to the heap objects point1 and point2, then all variable references to these objects would see these changes.
So, for example:
void main()
{
MyPoint a = new MyPoint { x = 1, y = 2 }; // point1
MyPoint b = new MyPoint { x = 3, y = 4 }; // point2
// Passed by value, but the properties x and y are being changed
DoSomething(a, b);
// a and b have been changed!
Assert.AreEqual(53, a.x);
Assert.AreEqual(21, b.y);
}
public void DoSomething(MyPoint a, MyPoint b)
{
a.x = 53;
b.y = 21;
}
Now, when execution returns to main, all references to point1 and point2, including main's variables a and b, which will now 'see' the changes when they next read the values for x and y of the points. You will also note that the variables a and b were still passed by value to DoSomething.
Changes to value types affect the local copy only
Value types (primitives like System.Int32, System.Double) and structs (like System.DateTime, or your own structs) are allocated on the stack, not the heap, and are copied verbatim onto the stack when passed into a call. This leads to a major difference in behaviour, since changes made by the called function to a value type field or property will only be observed locally by the called function, because it only will be mutating the local copy of the value type.
e.g. Consider the following code with an instance of the mutable struct, System.Drawing.Rectangle
public void SomeFunc(System.Drawing.Rectangle aRectangle)
{
// Only the local SomeFunc copy of aRectangle is changed:
aRectangle.X = 99;
// Passes - the changes last for the scope of the copied variable
Assert.AreEqual(99, aRectangle.X);
} // The copy aRectangle will be lost when the stack is popped.
// Which when called:
var myRectangle = new System.Drawing.Rectangle(10, 10, 20, 20);
// A copy of `myRectangle` is passed on the stack
SomeFunc(myRectangle);
// Test passes - the caller's struct has NOT been modified
Assert.AreEqual(10, myRectangle.X);
The above can be quite confusing and highlights why it is good practice to create your own custom structs as immutable.
The ref keyword works similarly to allow value type variables to be passed by reference, viz that the 'address' of the caller's value type variable is passed onto the stack, and assignment of the caller's assigned variable is now directly possible.
C# is actually pass by value. You get the illusion it's pass by reference, because when you pass a reference type you get a copy of the reference (the reference was passed by value). However, since your replace method is replacing that reference copy with another reference, it's effectively doing nothing (The copied reference goes out of scope immediately). You can actually pass by reference by adding the ref keyword:
void Replace<T>(ref T a, T b)
{
a = b;
}
This will get you your desired result, but in practice is a little strange.
In C# all the params that you pass to a method are passed by value.
Now before you shout keep on reading:
A value-type's value is the data that is copied while a reference type's value is actually a reference.
So when you pass an objects reference to a method and change that object then the changes will reflect outside the method as well since you are manipulating the same memory the object was allocated.
public void Func(Point p){p.x = 4;}
Point p = new Point {x=3,y=4};
Func(p);
// p.x = 4, p.y = 4
Now Lets look at this method:
public void Func2(Point p){
p = new Point{x=5,y=5};
}
Func2(p);
// p.x = 4, p.y = 4
So no changed occurred here and why? Your method simply created a new Point and changed p's reference(Which was passed by value) and therefore the change was local. You didn't manipulate the point, you changed the reference and you did locally.
And there comes the ref keyword that saves the day:
public void Func3(ref Point p){
p = new Point{x=5,y=5};
}
Func3(ref p);
// p.x = 5, p.y = 5
The same occurred in your example. You assigned a point with a new reference, but you did it locally.
C# is passing reference types objects not by reference, but rather it's passing the reference by value. Meaning you can mess around with their insides, but you can't change the assignment itself.
Read this great piece by Jon Skeet for deeper understanding.
Have a look on behavior by a simple program in C#:
class Program
{
static int intData = 0;
static string stringData = string.Empty;
public static void CallByValueForValueType(int data)
{
data = data + 5;
}
public static void CallByValueForRefrenceType(string data)
{
data = data + "Changes";
}
public static void CallByRefrenceForValueType(ref int data)
{
data = data + 5;
}
public static void CallByRefrenceForRefrenceType(ref string data)
{
data = data +"Changes";
}
static void Main(string[] args)
{
intData = 0;
CallByValueForValueType(intData);
Console.WriteLine($"CallByValueForValueType : {intData}");
stringData = string.Empty;
CallByValueForRefrenceType(stringData);
Console.WriteLine($"CallByValueForRefrenceType : {stringData}");
intData = 0;
CallByRefrenceForValueType(ref intData);
Console.WriteLine($"CallByRefrenceForValueType : {intData}");
stringData = string.Empty;
CallByRefrenceForRefrenceType(ref stringData);
Console.WriteLine($"CallByRefrenceForRefrenceType : {stringData}");
Console.ReadLine();
}
}
Output:
You're not understanding what passing by reference means. Your Replace method is creating a copy of the Point object--passing by value (which is actually the better way of doing it).
To pass by reference, so that a and b both reference the same point in memory, you need add "ref" to the signature.
You dont get it right.
It is similar like Java - everything is passed by value! But you do have to know, what the value is.
In primitive data types, the value is the number itself. In other cases it is reference.
BUT, if you copy reference to another variable, it holds same reference, but does not reference the variable (thus it is not pass by reference known in C++).
By default c# passes ALL arguements by value... that is why a and b remain unaffected in global scope in your examples. Here's a reference for those down voters.
To add more detail...in .NET, C# methods, using the default "pass by value" assigned to all parameters, reference types act differently in two scenarios. In the case of all reference types using classes (System.Object types), a copy of the "pointer" (to a memory block) to the original class or object is passed in and assigned to the method's parameter or variable name. This pointer is a value, too, and copied on the stack in memory where all value types are store. The value of the object isn't stored just a copy of its pointer, that points back to the original cl;ass object. I believe this is a 4-byte value. That's what is physically passed and stored in methods for all reference types. So, you now have a new method parameter or variable with a pointer assigned to it still pointing back to the original class object outside the method. You can now do two things to the new variable with the copied pointer value:
You can change the ORIGINAL object outside the method by changing its properties iniside your method. If "MyObject" is your variable with the copied pointer, you would do MyObject.myproperty = 6;, which changed the "myproperty" inside the original object outside the method. You did this as you passed in a pointer to the original object and assigned it to a new variable in your method. Note that this DOES change the referenced object outside the method.
Or, setting your variable with copied pointer to a new object and new pointer like so: MyObject = new SomeObject(); Here, we destroyed the old copied pointer assigned the variable above and assigned it to a new pointer to a new object! Now we have lost connection to the outside object and only changing a new object.
Consider the following code (I have purposefully written MyPoint to be a reference type for this example)
public class MyPoint
{
public int x;
public int y;
}
It is universally acknowledged (in C# at least) that when you pass by reference, the method contains a reference to the object being manipulated, whereas when you pass by value, the method copies the value being manipulated, thus the value in global scope is not affected.
Example:
void Replace<T>(T a, T b)
{
a = b;
}
int a = 1;
int b = 2;
Replace<int>(a, b);
// a and b remain unaffected in global scope since a and b are value types.
Here is my problem; MyPoint is a reference type, thus I would expect the same operation on Point to replace a with b in global scope.
Example:
MyPoint a = new MyPoint { x = 1, y = 2 };
MyPoint b = new MyPoint { x = 3, y = 4 };
Replace<MyPoint>(a, b);
// a and b remain unaffected in global scope since a and b...ummm!?
I expected a and b to point to the same reference in memory...can someone please clarify where I have gone wrong?
Re: OP's Assertion
It is universally acknowledged (in C# at least) that when you pass by reference, the method contains a reference to the object being manipulated, whereas when you pass by value, the method copies the value being manipulated ...
TL;DR
There's more to it than that. Unless you pass variables with the ref or out keywords, C# passes variables to methods by value, irrespective of whether the variable is a value type or a reference type.
If passed by reference, then the called function may change the variable's address at the call-site (i.e. change the original calling function's variable's assignment).
If a variable is passed by value:
if the called function re-assigns the variable, this change is local to the called function only, and will not affect the original variable in the calling function
however, if changes are made to the variable's fields or properties by the called function, it will depend on whether the variable is a value type or a reference type in order to determine whether the calling function will observe the changes made to this variable.
Since this is all rather complicated, I would recommend avoiding passing by reference if possible (instead, if you need to return multiple values from a function, use a composite class, struct, or Tuples as a return type instead of using the ref or out keywords on parameters)
Also, when passing reference types around, a lot of bugs can be avoided by not changing (mutating) fields and properties of an object passed into a method (for example, use C#'s immutable properties to prevent changes to properties, and strive to assign properties only once, during construction).
In Detail
The problem is that there are two distinct concepts:
Value Types (e.g. int) vs Reference Types (e.g. string, or custom classes)
Passing by Value (default behaviour) vs Passing by Reference(ref, out)
Unless you explicitly pass (any) variable by reference, by using the out or ref keywords, parameters are passed by value in C#, irrespective of whether the variable is a value type or reference type.
When passing value types (such as int, float or structs like DateTime) by value (i.e. without out or ref), the called function gets a copy of the entire value type (via the stack).
Any change to the value type, and any changes to any properties / fields of the copy will be lost when the called function is exited.
However, when passing reference types (e.g. custom classes like your MyPoint class) by value, it is the reference to the same, shared object instance which is copied and passed on the stack.
This means that:
If the passed object has mutable (settable) fields and properties, any changes to those fields or properties of the shared object are permanent (i.e. any changes to x or y are seen by anyone observing the object)
However, during method calls, the reference itself is still copied (passed by value), so if the parameter variable is reassigned, this change is made only to the local copy of the reference, so the change will not be seen by the caller. This is why your code doesn't work as expected
What happens here:
void Replace<T>(T a, T b) // Both a and b are passed by value
{
a = b; // reassignment is localized to method `Replace`
}
for reference types T, means that the local variable (stack) reference to the object a is reassigned to the local stack reference b. This reassign is local to this function only - as soon as scope leaves this function, the re-assignment is lost.
If you really want to replace the caller's references, you'll need to change the signature like so:
void Replace<T>(ref T a, T b) // a is passed by reference
{
a = b; // a is reassigned, and is also visible to the calling function
}
This changes the call to call by reference - in effect we are passing the address of the caller's variable to the function, which then allows the called method to alter the calling method's variable.
However, nowadays:
Passing by reference is generally regarded as a bad idea - instead, we should either pass return data in the return value, and if there is more than one variable to be returned, then use a Tuple or a custom class or struct which contains all such return variables.
Changing ('mutating') a shared value (and even reference) variable in a called method is frowned upon, especially by the Functional Programming community, as this can lead to tricky bugs, especially when using multiple threads. Instead, give preference to immutable variables, or if mutation is required, then consider changing a (potentially deep) copy of the variable. You might find topics around 'pure functions' and 'const correctness' interesting further reading.
Edit
These two diagrams may help with the explanation.
Pass by value (reference types):
In your first instance (Replace<T>(T a,T b)), a and b are passed by value. For reference types, this means the references are copied onto the stack and passed to the called function.
Your initial code (I've called this main) allocates two MyPoint objects on the managed heap (I've called these point1 and point2), and then assigns two local variable references a and b, to reference the points, respectively (the light blue arrows):
MyPoint a = new MyPoint { x = 1, y = 2 }; // point1
MyPoint b = new MyPoint { x = 3, y = 4 }; // point2
The call to Replace<Point>(a, b) then pushes a copy of the two references onto the stack (the red arrows). Method Replace sees these as the two parameters also named a and b, which still point to point1 and point2, respectively (the orange arrows).
The assignment, a = b; then changes the Replace methods' a local variable such that a now points to the same object as referenced by b (i.e. point2). However, note that this change is only to Replace's local (stack) variables, and this change will only affect subsequent code in Replace (the dark blue line). It does NOT affect the calling function's variable references in any way, NOR does this change the point1 and point2 objects on the heap at all.
Pass by reference:
If however we we change the call to Replace<T>(ref T a, T b) and then change main to pass a by reference, i.e. Replace(ref a, b):
As before, two point objects allocated on the heap.
Now, when Replace(ref a, b) is called, while mains reference b (pointing to point2) is still copied during the call, a is now passed by reference, meaning that the "address" to main's a variable is passed to Replace.
Now when the assignment a = b is made ...
It is the the calling function, main's a variable reference which is now updated to reference point2. The change made by the re-assignment to a is now seen by both main and Replace. There are now no references to point1
Changes to (heap allocated) object instances are seen by all code referencing the object
In both scenarios above, no changes were actually made to the heap objects, point1 and point2, it was only local variable references which were passed and re-assigned.
However, if any changes were actually made to the heap objects point1 and point2, then all variable references to these objects would see these changes.
So, for example:
void main()
{
MyPoint a = new MyPoint { x = 1, y = 2 }; // point1
MyPoint b = new MyPoint { x = 3, y = 4 }; // point2
// Passed by value, but the properties x and y are being changed
DoSomething(a, b);
// a and b have been changed!
Assert.AreEqual(53, a.x);
Assert.AreEqual(21, b.y);
}
public void DoSomething(MyPoint a, MyPoint b)
{
a.x = 53;
b.y = 21;
}
Now, when execution returns to main, all references to point1 and point2, including main's variables a and b, which will now 'see' the changes when they next read the values for x and y of the points. You will also note that the variables a and b were still passed by value to DoSomething.
Changes to value types affect the local copy only
Value types (primitives like System.Int32, System.Double) and structs (like System.DateTime, or your own structs) are allocated on the stack, not the heap, and are copied verbatim onto the stack when passed into a call. This leads to a major difference in behaviour, since changes made by the called function to a value type field or property will only be observed locally by the called function, because it only will be mutating the local copy of the value type.
e.g. Consider the following code with an instance of the mutable struct, System.Drawing.Rectangle
public void SomeFunc(System.Drawing.Rectangle aRectangle)
{
// Only the local SomeFunc copy of aRectangle is changed:
aRectangle.X = 99;
// Passes - the changes last for the scope of the copied variable
Assert.AreEqual(99, aRectangle.X);
} // The copy aRectangle will be lost when the stack is popped.
// Which when called:
var myRectangle = new System.Drawing.Rectangle(10, 10, 20, 20);
// A copy of `myRectangle` is passed on the stack
SomeFunc(myRectangle);
// Test passes - the caller's struct has NOT been modified
Assert.AreEqual(10, myRectangle.X);
The above can be quite confusing and highlights why it is good practice to create your own custom structs as immutable.
The ref keyword works similarly to allow value type variables to be passed by reference, viz that the 'address' of the caller's value type variable is passed onto the stack, and assignment of the caller's assigned variable is now directly possible.
C# is actually pass by value. You get the illusion it's pass by reference, because when you pass a reference type you get a copy of the reference (the reference was passed by value). However, since your replace method is replacing that reference copy with another reference, it's effectively doing nothing (The copied reference goes out of scope immediately). You can actually pass by reference by adding the ref keyword:
void Replace<T>(ref T a, T b)
{
a = b;
}
This will get you your desired result, but in practice is a little strange.
In C# all the params that you pass to a method are passed by value.
Now before you shout keep on reading:
A value-type's value is the data that is copied while a reference type's value is actually a reference.
So when you pass an objects reference to a method and change that object then the changes will reflect outside the method as well since you are manipulating the same memory the object was allocated.
public void Func(Point p){p.x = 4;}
Point p = new Point {x=3,y=4};
Func(p);
// p.x = 4, p.y = 4
Now Lets look at this method:
public void Func2(Point p){
p = new Point{x=5,y=5};
}
Func2(p);
// p.x = 4, p.y = 4
So no changed occurred here and why? Your method simply created a new Point and changed p's reference(Which was passed by value) and therefore the change was local. You didn't manipulate the point, you changed the reference and you did locally.
And there comes the ref keyword that saves the day:
public void Func3(ref Point p){
p = new Point{x=5,y=5};
}
Func3(ref p);
// p.x = 5, p.y = 5
The same occurred in your example. You assigned a point with a new reference, but you did it locally.
C# is passing reference types objects not by reference, but rather it's passing the reference by value. Meaning you can mess around with their insides, but you can't change the assignment itself.
Read this great piece by Jon Skeet for deeper understanding.
Have a look on behavior by a simple program in C#:
class Program
{
static int intData = 0;
static string stringData = string.Empty;
public static void CallByValueForValueType(int data)
{
data = data + 5;
}
public static void CallByValueForRefrenceType(string data)
{
data = data + "Changes";
}
public static void CallByRefrenceForValueType(ref int data)
{
data = data + 5;
}
public static void CallByRefrenceForRefrenceType(ref string data)
{
data = data +"Changes";
}
static void Main(string[] args)
{
intData = 0;
CallByValueForValueType(intData);
Console.WriteLine($"CallByValueForValueType : {intData}");
stringData = string.Empty;
CallByValueForRefrenceType(stringData);
Console.WriteLine($"CallByValueForRefrenceType : {stringData}");
intData = 0;
CallByRefrenceForValueType(ref intData);
Console.WriteLine($"CallByRefrenceForValueType : {intData}");
stringData = string.Empty;
CallByRefrenceForRefrenceType(ref stringData);
Console.WriteLine($"CallByRefrenceForRefrenceType : {stringData}");
Console.ReadLine();
}
}
Output:
You're not understanding what passing by reference means. Your Replace method is creating a copy of the Point object--passing by value (which is actually the better way of doing it).
To pass by reference, so that a and b both reference the same point in memory, you need add "ref" to the signature.
You dont get it right.
It is similar like Java - everything is passed by value! But you do have to know, what the value is.
In primitive data types, the value is the number itself. In other cases it is reference.
BUT, if you copy reference to another variable, it holds same reference, but does not reference the variable (thus it is not pass by reference known in C++).
By default c# passes ALL arguements by value... that is why a and b remain unaffected in global scope in your examples. Here's a reference for those down voters.
To add more detail...in .NET, C# methods, using the default "pass by value" assigned to all parameters, reference types act differently in two scenarios. In the case of all reference types using classes (System.Object types), a copy of the "pointer" (to a memory block) to the original class or object is passed in and assigned to the method's parameter or variable name. This pointer is a value, too, and copied on the stack in memory where all value types are store. The value of the object isn't stored just a copy of its pointer, that points back to the original cl;ass object. I believe this is a 4-byte value. That's what is physically passed and stored in methods for all reference types. So, you now have a new method parameter or variable with a pointer assigned to it still pointing back to the original class object outside the method. You can now do two things to the new variable with the copied pointer value:
You can change the ORIGINAL object outside the method by changing its properties iniside your method. If "MyObject" is your variable with the copied pointer, you would do MyObject.myproperty = 6;, which changed the "myproperty" inside the original object outside the method. You did this as you passed in a pointer to the original object and assigned it to a new variable in your method. Note that this DOES change the referenced object outside the method.
Or, setting your variable with copied pointer to a new object and new pointer like so: MyObject = new SomeObject(); Here, we destroyed the old copied pointer assigned the variable above and assigned it to a new pointer to a new object! Now we have lost connection to the outside object and only changing a new object.
What's the better way of implementing a swap function? How would using ref be better than using out, or vice versa? Any other benefits or drawbacks that will occur from using one or the other?
swapref(ref T a, ref T b) {
T temp = a;
a = b;
b = temp;
}
swapout(out T a, out T b)
{
T temp = a;
a = b;
b = temp;
}
By definition a Swap() function requires that the parameters passed have values. Therefore you should use ref.
Using out would imply that (and allow) uninitialized parameters could be passed (and in fact should not compile since you would be using an unassigned parameter)
If I modify your swapout method to something closer to compiling...
static void swapout<T>(out T a, out T b)
{
T temp = a; // ERROR: Use of unassigned out parameter 'a'
a = b; // ERROR: Use of unassigned out parameter 'b'
b = temp;
}
...it still produces the errors you see in the comments.
When a parameter is modified with out it is treated as uninitialized and it is the responsibility of the method to assign it a definite value. The whole point of a swap method is to operate on values passed to it, but with out the values of those parameters are off limits because the caller is not required to pass an initialized variable. Therefore, to answer your question, not only is using ref the superior solution, but using out is not a workable solution at all.
Definite assignment is a big deal in C#, it keeps you out of trouble by ensuring that your code has assigned a value to a variable before it is used. The core reason that the language distinguishes between ref and out. Other languages don't draw this distinction, they just have syntax for "pass by value" vs "pass by reference". In VB.NET that's ByVal vs ByRef for example. By using out instead of ref you clearly state the data flow and promise that the variable doesn't have to be assigned before the call and will be assigned afterwards. The compiler verifies this and complains if you break that rule.
What you can't do is swap a "not assigned" state. No syntax exists that lets you express that a variable is not assigned after an operation. It therefore follows that you must use ref. Nullable gives you options, not in scope here.
I was looking at this question, and aside from a rather odd way to enumerate something, the op was having trouble because the enumerator is a struct. I understand that returning or passing a struct around uses a copy because it is a value type:
public MyStruct GetThingButActuallyJustCopyOfIt()
{
return this.myStructField;
}
or
public void PretendToDoSomething(MyStruct thingy)
{
thingy.desc = "this doesn't work as expected";
}
So my question is if MyStruct implements IMyInterface (such as IEnumerable), will these types of methods work as expected?
public struct MyStruct : IMyInterface { ... }
//will caller be able to modify the property of the returned IMyInterface?
public IMyInterface ActuallyStruct() { return (IMyInterface)this.myStruct; }
//will the interface you pass in get its value changed?
public void SetInterfaceProp(IMyInterface thingy)
{
thingy.desc = "the implementing type is a struct";
}
Yes, that code will work, but it needs explanation, because there is a whole world of code that will not work, and you're likely to trip into that unless you know this.
Before I forget: Mutable structs are evil. OK, with that out of the way, let's move on.
Let's take a simple example, you can use LINQPad to verify this code:
void Main()
{
var s = new MyStruct();
Test(s);
Debug.WriteLine(s.Description);
}
public void Test(IMyInterface i)
{
i.Description = "Test";
}
public interface IMyInterface
{
string Description { get; set; }
}
public struct MyStruct : IMyInterface
{
public string Description { get; set; }
}
When executing this, what will be printed?
null
OK, so why?
Well, the problem is this line:
Test(s);
This will in fact box that struct and pass the boxed copy to the method. You're successfully modifying that boxed copy, but not the original s variable, which was never assigned anything, and is thus still null.
OK, so if we change just one line in the first piece of code:
IMyInterface s = new MyStruct();
Does this change the outcome?
Yes, because now you're boxing that struct here, and always use the boxed copy. In this context it behaves like an object, you're modifying the boxed copy and writing out the contents of the boxed copy.
The problem thus crops up whenever you box or unbox that struct, then you get copies that live separate lives.
Conclusion: Mutable structs are evil.
I see two answers about using ref here now, and this is barking up the wrong tree. Using ref means you've solved the problem before you added ref.
Here's an example.
If we change the Test method above to take a ref parameter:
public void Test(ref IMyInterface i)
Would this change anything?
No, because this code is now invalid:
var s = new MyStruct();
Test(ref s);
You'll get this:
The best overloaded method match for 'UserQuery.Test(ref UserQuery.IMyInterface)' has some invalid arguments
Argument 1: cannot convert from 'ref UserQuery.MyStruct' to 'ref UserQuery.IMyInterface'
And so you change the code to this:
IMyInterface s = new MyStruct();
Test(ref s);
But now you're back to my example, just having added ref, which I showed is not necessary for the change to propagate back.
So using ref is orthogonal, it solves different problems, but not this one.
OK, more comments regarding ref.
Yes, of course passing a struct around using ref will indeed make the changes flow throughout the program.
That is not what this question was about. The question posted some code, asked if it would work, and it would. In this particular variant of code it would work. But it's so easy to trip up. And pay particular note that the question was regarding structs and interfaces. If you leave interfaces out of it, and pass the struct around using ref, then what do you have? A different question.
Adding ref does not change this question, nor the answer.
Within the CLR, every value-type definition actually defines two kinds of things: a structure type, and a heap object type. A widening conversion exists from the structure type to the boxed object type, and a narrowing conversion exists from Object to the structure type. The structure type will behave with value semantics, and the heap object type will behave with mutable reference semantics. Note that the heap object types associated with all non-trivial structure types [i.e. those with any non-default states] are always mutable, and nothing in the structure definition can cause them to be otherwise.
Note that value types may be constrained, cast, or coerced to interface types, and cast or coerced to reference types. Consider:
void DoSomethingWithDisposable<T,U>(ref T p1,
List<int>.Enumerator p2) where T:IDisposable
{
IDisposable v1a = p1; // Coerced
Object v1b = p1; // Coerced
IDisposable v2a = (IDisposable)p2; // Cast
Object v2b = (Object)p2; // Cast
p1.Dispose(); // Constrained call
}
void blah( List<string>.Enumerator p1, List<int>.Enumerator p2) // These are value types
{
DoSomethingWithDisposable(p1,p2); // Constrains p1 to IDisposable
}
Constraining a generic type to an interface type does not affect its behavior as a value type. Casting or coercing an a value type to an interface or reference type, however, will create a new instance of the heap object type and return a reference to that. That reference will then behave with reference-type semantics.
The behavior of value types with generic constraints can at times be very useful, and such usefulness can apply even when using mutating interfaces, but unfortunately there's no way to tell the compiler that a value type must remain as a value type, and that the compiler should warn if it would find itself converting it to something else. Consider the following three methods:
bool AdvanceIntEnumerator1(IEnumerator<int> it)
{ return it.MoveNext(); }
bool AdvanceIntEnumerator2(ref T it) where T:IEnumerator<int>
{ return it.MoveNext(); }
bool AdvanceIntEnumeratorTwice<T>(ref T it) where T:IEnumerator<int>
{ return it.MoveNext() && AdvanceIntEnumerator1(it); }
If one passes to the first piece of code a variable of type List<int>.Enumerator, the system will copy its state to a new heap object, call MoveNext on that object, and abandon it. If one passes instead a variable of type IEnumerator<int> which holds a reference to a heap object of type List<int>.Enumerator, it will call MoveNext on that instance, which the calling code will still retain.
If one passes to the second piece of code a variable of type List<int>.Enumerator, the system will call MoveNext on that variable, thus changing its state. If one passes a variable of type IEnumerable<T>, the system will call MoveNext on the object referred to by that variable; the variable won't be modified (it will still point to the same instance), but the instance to which it points will be.
Passing to the third piece of code a variable of type List<int>.Enumerator will cause MoveNext to be called on that variable, thus changing its state. If that returns true, the system will copy the already-modified variable to a new heap object and call MoveNext on that. The object will then be abandoned, so the variable will only be advanced once, but the return value will indicate whether a second MoveNext would have succeeded. Passing the third piece of code a variable of type IEnumerator<T> which holds a reference to a List<T>.Enumerator, however, will cause that instance to be advanced twice.
No, interface is a contract, to make it work properly you need to use ref keyword.
public void SetInterfaceProp(ref IMyInterface thingy)
{
thingy.desc = "the implementing type is a struct";
}
What matters here is a real type that stays inside that interface wrap.
To be more clear:
even if code with method SetInterfaceProp defined like
public void SetInterfaceProp(IMyInterface thingy)
{
thingy.desc = "the implementing type is a struct";
}
will work:
IMyInterface inter= default(MyStruct);
SetInterfaceProp(inter);
this one will not :
MyStruct inter = default(MyStruct);
SetInterfaceProp(inter);
You can not gurantee that the caller of your method will always use IMyInterface, so to guarantee expected behavior, in this case, you can define ref keyword, that will guarantee that in both cases method would run as expected.
I have created a generic type to act as a pointer so that I can pass by reference. (Perhaps there is a much more simple way of doing this but I want to stress that I am doing this to learn more about generics and passing by reference, not the most efficient way of completing the task, if that makes sense.)
Here is the code I wrote for the generic type
class GenericPointer<T> {
public T item;
public void setItem(T i){ item = i; }
public T getItem(){ return item; }
}
In my program I have created an instance of this type called 'intPointer'. The value 143 is arbitrary.
GenericPointer<int> intPointer = new GenericPointer<int>();
intPointer.setItem(143);
Console.WriteLine(intPointer.getItem());
The above code runs properly, setting and returning the value 143.
I now want to pass this 'intPointer' to a method that increments it and then prints the value again.
So I wrote a method called addone()
public void addone(int i) { i ++; }
Now I want to make the following calls (remembering that I already set the value to 143):
Console.WriteLine(intPointer.getItem());
addone(intPointer);
Console.WriteLine(intPointer.getItem());
What I was expecting to see was 143 then 144 however I get the following errors:
The best overloaded method match for 'Notes.Program.addone(int)' has some invalid arguments
and:
cannot convert from 'Notes.GenericPointer<int>' to 'int'
Any help would be greatly appreciated!
I'll begin by correcting some of your terminology: you're not using pointers. C# does support pointers, but using the unsafe keyword, and they are real pointers (as in, integer memory addresses you can directly manipulate). The code you written is just an example of a boxed object.
.NET supports boxing already, by casting to Object; however it isn't recommended nor needed because the ref keyword solves the problem you're trying to "fix".
Use the ref keyword to describe a value-type parameter that should be passed by-reference instead of by-value. All other semantics remain the same, like so:
void Foo() {
int x = 123;
Bar(ref x);
Console.Write( x ); // prints "124".
}
void Bar(ref int x) {
x++;
}
I have a few other notes:
C# and .NET conventions dictate that all public members (methods, properties, fields, etc) should have TitleCase, not camelCase (i.e. ensure the first letter is capitalised).
Trivial getter and setter methods are discouraged, used Properties instead (though I note you cannot use ref arguments with properties).
You're getting your error because the type of intPointer is not int, but your class GenericPointer<int>.
While GenericPointer is wrapping an int, it is not actually an int so it cannot be treated as one. It has properties that are an int.
Imagine if GenericPointer wrapped a string. What would AddOne do to that.
You can act on the properties of the class but not treat the entire class as its generic type.
It would be possible to write an AddOne method that took a Generic Pointer argument and then inspected it for intyness and then added one to the internal item if it was an int. I am sure that is not a good idea.
What are you really trying to achieve with this GenericPointer?
If you want parameters to be reference if they are a value type (string, int, bool, etc.) then make your parameter like this:
public void addone(ref int i)
{
i++;
}
Then call the method like so:
addone(ref variableInt);
You can also look at this in order to see how to make your classes work as a specific type.