Why Use the 'Ref' Keyword When Passing an Object

Why use the 'ref' keyword when passing an object?

Pass a ref if you want to change what the object is:

TestRef t = new TestRef();
t.Something = "Foo";
DoSomething(ref t);

void DoSomething(ref TestRef t)
{
  t = new TestRef();
  t.Something = "Not just a changed t, but a completely different TestRef object";
}

After calling DoSomething, t does not refer to the original new TestRef, but refers to a completely different object.

This may be useful too if you want to change the value of an immutable object, e.g. a string. You cannot change the value of a string once it has been created. But by using a ref, you could create a function that changes the string for another one that has a different value.

It is not a good idea to use ref unless it is needed. Using ref gives the method freedom to change the argument for something else, callers of the method will need to be coded to ensure they handle this possibility.

Also, when the parameter type is an object, then object variables always act as references to the object. This means that when the ref keyword is used you've got a reference to a reference. This allows you to do things as described in the example given above. But, when the parameter type is a primitive value (e.g. int), then if this parameter is assigned to within the method, the value of the argument that was passed in will be changed after the method returns:

int x = 1;
Change(ref x);
Debug.Assert(x == 5);
WillNotChange(x);
Debug.Assert(x == 5); // Note: x doesn't become 10

void Change(ref int x)
{
  x = 5;
}

void WillNotChange(int x)
{
  x = 10;
}

When to pass ref keyword in

Let me break that down into two questions:

1) When should one use ref/out formal parameter declarations when writing a method?

Use ref/out when you desire your method to be able to read and write a variable passed in from the caller, rather than merely reading a value.

2) Why does an "extract method" refactoring produce a ref parameter?

I don't know the details of Resharper, but I can make a guess. Consider the following evil mutable value type:

struct S 
{ 
  private int x;
  public int X() { return this.x; } 
  public void M() { this.x += 1; } 
}

You have a method:

void Foo() 
{
    S s = new S();
    Fred(s);
    Blah(s);
    Bar(s);
    s.M();
    Console.WriteLine(s.X()); // prints 1
}

and you do "extract method" on the middle bit:

void NewMethod(ref S s)
{
    Blah(s);
    Bar(s);
    s.M();
}

void Foo() 
{
    S s = new S();
    Fred(s);
    NewMethod(ref s);
    Console.WriteLine(s.X()); // still prints 1
}

If instead you made a method without "ref" then calling NewMethod(s) would pass a copy of s to NewMethod. Remember, value types are copied by value; that's why we called them "value types". It would be the copy that gets mutated, and then s.X() returns zero. It is a bad idea for a refactoring to introduce a semantic change in a program, and it is difficult for a refactoring engine to know whether a given method relies on the mutability of a value type or not.

This is just another reason why you should avoid mutable value types.

Use of 'ref' keyword in C#

Using ref means that the reference is passed to the function.

The default behaviour is that the function receives a new reference to the same object. This means if you change the value of the reference (e.g. set it to a new object) then you are no longer pointing to the original, source object. When you pass using ref then changing the value of the reference changes the source reference - because they are the same thing.

Consider this:

public class Thing
{
    public string Property {get;set;}
}

public static void Go(Thing thing)
{
    thing = new Thing();
    thing.Property = "Changed";
}

public static void Go(ref Thing thing)
{
    thing = new Thing();
    thing.Property = "Changed";
}

Then if you run

var g = new Thing();

// this will not alter g
Go(g);

// this *will* alter g
Go(ref g);

What is the advantage of using the ref keyword with a reference type parameter?

What do I gain, as the developer, by passing a reference type argument to a method using the ref keyword if you are not changing what the reference points to?

None whatsoever - that's the only purpose of passing a reference type by reference is if you are going to change what the reference refers to.

To be fair - it gives you the ability to change that behavior in the future, which would be sadistic and cruel...

Why is the `ref` keyword not mandatory here?

ref is ment to be used when you change the reference, not the referenced instance. So you can modify the referenced instance without using ref, however when you want to reference another object, you have to use ref

Having said this Fill will just modify what was passed to it, it won´t create a new DataTable.

On the other hand when you want to return another instance, you have to use ref:

void DoSomething(ref dt)
{
    dt = new DataTable();
    // do something with the new table
}

Now you have two tables, one that was passed to DoSomething and a second one that was created within that method and that doesn´t have anything in common with the former. However the calling code references that new instance now, the original reference is lost.

What is the use of ref for reference-type variables in C#?

You can change what foo points to using y:

Foo foo = new Foo("1");

void Bar(ref Foo y)
{
    y = new Foo("2");
}

Bar(ref foo);
// foo.Name == "2"

ref keyword and reference types

Let

class A
{
    public string Blah { get; set; }
}

void Do (ref A a)
{
    a = new A { Blah = "Bar" };
}

then

A a = new A { Blah = "Foo" };
Console.WriteLine(a.Blah); // Foo
Do (ref a);
Console.WriteLine(a.Blah); // Bar

---

But if just

void Do (A a)
{
    a = new A { Blah = "Bar" };
}

then

A a = new A { Blah = "Foo" };
Console.WriteLine(a.Blah); // Foo
Do (a);
Console.WriteLine(a.Blah); // Foo

---

Related Topics