What's the point of passing a parameter by reference in C#? [duplicate]

Question

Possible Duplicate:
Why are objects passed by reference?

Doesn't C# send the objects themselves? So unless it's some kind of swap function for primitive typed variables - why would I send an object by reference?

Answer 1

C# doesn't pass the objects themselves. C# passes whatever's in the stack. For value types that are locally-scoped and thus live on the stack, the value is passed down to the next level of the call stack. For all other objects, the data is on the heap and a reference to the heap address is stored on the stack, and is passed around.

In either case, the data that resides on the stack, whether that's the data you care about or a reference "pointer" to the data you care about, is not changed, because when it is passed, it is copied to a new location on the stack and that value is what is manipulated (and then discarded when the method exits and that frame pops off the call stack). If you pass a value type to a method that changes the value, when that method returns to its caller the value will be unchanged, because that copy of the data was never touched by the method. If you pass a reference type, it is the reference that is copied. This means that the data on the heap, pointed to by the reference, can be altered and that will change the data for the caller. BUT, if the passed parameter is reinitialized or otherwise assigned to a different reference, that change will be reverted when the method returns, because that is a change to the reference to the object, which was passed "by value" and doesn't affect the caller's copy of that reference.

For proof, run this test in NUnit:

    [Test]
    public void TestPassObject()
    {
        //instantiate a new instance of some reference type
        var myObj = new object();

        //make a "shallow" copy. This copy will never be touched.
        var myLocalCopy = myObj;

        //Pass the original copy by reference to a method that will alter it.
        var result = TestMethod(myObj);

        //Our original reference value did not change even though
        //the passed reference was reinstantiated.
        //myObj and myLocalCopy are still the same object...
        Assert.AreEqual(myObj, myLocalCopy);
        //and are different from result, even though TestMethod 
        //assigned the reference in result to its passed myObj parameter.
        Assert.AreNotEqual(myObj, result);
    }

    private object TestMethod(object myObj)
    {
        //myObj is a local "copy" of the reference passed by the caller.
        //if you changed myObj's children, the caller would see that,
        //but reinitializing it points the copy to new data on the heap,
        //and does not affect the caller.
        return myObj = new object();
    }

So given that default behavior when not using ref, the answer to your question is that the ref keyword changes what is passed. Instead of passing a copy of the value that resides on the stack, a parameter with the ref keyword is given a "pointer" to the data residing on the stack, whether that's a data value itself or a reference to a data value on the heap. I put "pointer" in quotes because the term is anathema to most .NET coders, but dig down deep enough and that's pretty much what's going on; you're given an immutable pointer to that element of the caller's stack frame.

Behind the scenes, when you use or alter the passed ref parameter, you are using or changing the value of the caller's copy, as pointed to by the ref parameter. This is true regardless of what was passed (data, or a reference to data). This means that you can change a value type's data, or reinitialize/reassign a reference type's reference, and that will affect the caller. However, the syntax remains the same, because the C# spec says it must be so to avoid the confusion that C++ has; in C++, when dealing with a child of your passed parameter, you have to know whether you were given a pointer to an object and must use ., or a pointer to a pointer to an object and must use -> (or a pointer to a pointer to a pointer to an object and must double-dereference, etc etc).

Answer 2

When you pass an object by reference, you can change the value of the reference.

Let's say you have a Person class:

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    public override string ToString()
    {
        return String.Format("Name: {0} - Age: {1}", Name, Age);
    }
}

You also have these functions:

private static void NormalChangeProperties(Person person)
{
    person.Name = "Bob";
    person.Age = 17;
}

private static void NormalAssignNewPerson(Person person)
{
    person = new Person { Age = 55, Name = "John" };
}

private static void NormalSetNull(Person person)
{
    person = null;
}

private static void ByRefChangeProperties(ref Person person)
{
    person.Name = "Bob";
    person.Age = 17;
}

private static void ByRefAssignNewPerson(ref Person person)
{
    person = new Person { Age = 55, Name = "John" };
}

private static void ByRefSetNull(ref Person person)
{
    person = null;
}

And then you have this console app:

static void Main(string[] args)
{
    Person p = new Person { Age = 29, Name = "Kristof" };
    Console.WriteLine("Initial: {0}", p);

    NormalChangeProperties(p);
    Console.WriteLine("After NormalChangeProperties: {0}", p);

    NormalAssignNewPerson(p);
    Console.WriteLine("After NormalAssignNewPerson: {0}", p);

    NormalSetNull(p);
    Console.WriteLine("After NormalSetNull: {0}", p);

    Console.WriteLine("");
    Console.WriteLine("");

    Person p2 = new Person { Age = 29, Name = "Kristof" };
    Console.WriteLine("Initial: {0}", p2);

    ByRefChangeProperties(ref p2);
    Console.WriteLine("After ByRefChangeProperties: {0}", p2);

    ByRefAssignNewPerson(ref p2);
    Console.WriteLine("After ByRefAssignNewPerson: {0}", p2);

    ByRefSetNull(ref p2);
    Console.WriteLine("After ByRefSetNull: {0}", p2 != null ? p2.ToString() : "null");

    Console.ReadLine();
}

The output will be:

Initial: Name: Kristof - Age: 29
After NormalChangeProperties: Name: Bob - Age: 17
After NormalAssignNewPerson: Name: Bob - Age: 17
After NormallSetNull: Name: Bob - Age: 17


Initial: Name: Kristof - Age: 29
After ByRefChangeProperties: Name: Bob - Age: 17
After ByRefAssignNewPerson: Name: John - Age: 55
After ByRefSetNull: null

As you can see, assigning a new value (as opposed to changing properties) or setting it to null (which is also changing the value) of the reference itself, requires you pass by reference.

For a better and more detailed explanation, you can have a look at this article by Jon Skeet.

Answer 3

It is necessary to use when you want a method to modify a value type or modify a reference to a reference type, The most commmon reason for doing either of these in code I've seen is interop with C || C++ libraries, e.g. ref int is marshalled to *int.

In pure managed code it tends to be rarer to need ref or out as you mainly use reference types which already give you references to objects rather than copies of objects like value types do. i.e. one level of indirection is all you need most of the time (indeed if you need ref a lot you may be a three star programmer ;)

Answer 4

Making a deep copy of an object is a potentially very expensive operation in terms of both memory and CPU. In some cases (DataTable and friends come to mind), there is even code in place that prevents naive deep copying, although one could question here what is cause and what is effect. If the type of the instance has any sort of global state, making a naive deep copy could potentially be dangerous.

On the other hand, making a deep copy of the value of a primitively-typed variable is quite cheap, and in some cases (for example, immutability of strings) comes essentially for free.

Generally, I feel that functions should not touch their input parameters unless the caller actually wants it to. An easy way to ensure that the caller at least is aware that the callee might alter the input is to require passing by reference, either ref or out as appropriate.

Answer 5

C# sends references to objects all the time. That is, when you do

void Bar (myObject obj)
{
    obj.Name = "Hi";
    obj = new myObject();
}

obj is a value that contains a reference to an instance of myObject allocated on the heap. If we get behind the metaphor of passing entire objects in any sort of way, it's really not at all different from an integer. The reference itself is passed by value (by being copied byte by byte), but the thing the reference points to obviously stays the same.

When you use the ref keyword, what you pass is a reference to a variable (note the emphasis; compare with the above). ref int would be a reference to an integer variable. Again, the reference is copied byte by byte (a process that is completely opaque to you), but the thing the reference points to stays the same.

So, just like obj is a reference to an instance of myObject, ref myObject obj2 would be a reference to a variable containing a reference to an instance of an object, or in other words, a reference to a reference of myObject.

The out keyword does the same thing, except that the reference is assumed to point to null.

Okay, now that we've gotten past that, let's contend with the question of why the hell do this.

Well, the short answer is, do not use the ref keyword. The slightly longer answer is, Do not use the ref keyword unless you really can't avoid it.. Especially do not use it with anything except local variables (e.g. do not use it with fields and the like), and really really don't use it on reference types.

There are several reasons for this rationale. First of all, keeping the number of function returns at a minimum helps comprehension. It reduces the number of diverging pathways your code can possibly take.

Then, passing things by reference opens up a whole slew of nasty typing and mutability problems. Let's say I have an instance MyChild : MyParent, and there is a method that takes MyParent by reference. When I pass MyChild to the method, I can never know if I'm getting an object of type MyChild back. In broader terms, you really have no idea what sort of object you'll be getting back when you send something in by ref. It could be the same instance, it could be another instance, it could be another type altogether.

Answer 6

Send objects by reference when you want to have the possibility of modifying the original object. Otherwise, send by value if you just need the value of the object.

Passing by reference happens all the time and isn't just for swap functions.