312

If I am passing an object to a method, why should I use the ref keyword? Isn't this the default behaviour anyway?

For example:

class Program
{
    static void Main(string[] args)
    {
        TestRef t = new TestRef();
        t.Something = "Foo";

        DoSomething(t);
        Console.WriteLine(t.Something);
    }

    static public void DoSomething(TestRef t)
    {
        t.Something = "Bar";
    }
}


public class TestRef
{
    public string Something { get; set; }
}

The output is "Bar" which means that the object was passed as a reference.

Jim Fell
  • 12,390
  • 29
  • 117
  • 192
Ryan
  • 4,331
  • 3
  • 21
  • 21

11 Answers11

315

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;
}
Neuron
  • 3,776
  • 3
  • 24
  • 44
Scott Langham
  • 53,246
  • 34
  • 122
  • 193
89

You need to distinguish between "passing a reference by value", and "passing a parameter/argument by reference".

I've written a reasonably long article on the subject to avoid having to write carefully each time this comes up on newsgroups

Neuron
  • 3,776
  • 3
  • 24
  • 44
Jon Skeet
  • 1,261,211
  • 792
  • 8,724
  • 8,929
  • 1
    Well I encountered the issue while upgrading VB6 into .Net C# code. There are function/method signatures that take ref, out and plain parameters. So how can we better distinguish the difference between a plain param vs a ref? – bonCodigo Mar 18 '15 at 10:20
  • 2
    @bonCodigo: Not sure what you mean by "better distinguish" - it's part of the signature, and you have to specify `ref` at the call site as well... where else would you want it to be distinguished? The semantics are reasonably clear too, but need to be expressed carefully (rather than "objects are passed by reference" which is the common over-simplification). – Jon Skeet Mar 18 '15 at 10:43
  • i dont know why visual studio still doesnt show explicitly what is passed – MonsterMMORPG Apr 05 '17 at 12:09
  • 3
    @MonsterMMORPG: I don't know what you mean by that, I'm afraid. – Jon Skeet Apr 05 '17 at 13:04
60

In .NET when you pass any parameter to a method, a copy is created. In value types means that any modification you make to the value is at the method scope, and is lost when you exit the method.

When passing a Reference Type, a copy is also made, but it is a copy of a reference, i.e. now you have TWO references in memory to the same object. So, if you use the reference to modify the object, it gets modified. But if you modify the reference itself - we must remember it is a copy - then any changes are also lost upon exiting the method.

As people have said before, an assignment is a modification of the reference, thus is lost:

public void Method1(object obj) {   
 obj = new Object(); 
}

public void Method2(object obj) {  
 obj = _privateObject; 
}

The methods above does not modifies the original object.

A little modification of your example

 using System;

    class Program
        {
            static void Main(string[] args)
            {
                TestRef t = new TestRef();
                t.Something = "Foo";

                DoSomething(t);
                Console.WriteLine(t.Something);

            }

            static public void DoSomething(TestRef t)
            {
                t = new TestRef();
                t.Something = "Bar";
            }
        }



    public class TestRef
    {
    private string s;
        public string Something 
        { 
            get {return s;} 
            set { s = value; }
        }
    }
dipdapdop
  • 125
  • 1
  • 10
Ricardo Amores
  • 4,423
  • 1
  • 27
  • 44
  • 9
    I like this answer better then the accepted answer. It explains more clearly what is happening when passing a reference type variable with the ref keyword. Thank you! – Stefan Feb 26 '18 at 13:49
18

Since TestRef is a class (which are reference objects), you can change the contents inside t without passing it as a ref. However, if you pass t as a ref, TestRef can change what the original t refers to. i.e. make it point to a different object.

Ferruccio
  • 93,779
  • 37
  • 217
  • 294
16

With ref you can write:

static public void DoSomething(ref TestRef t)
{
    t = new TestRef();
}

And t will be changed after the method has completed.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Rinat Abdullin
  • 21,550
  • 8
  • 54
  • 80
  • And if ref was not specified then t is the same object with all properties reset to initial values. As far as the caller is concerned, the passed in argument will always have properties reset. What's the point of doing this? – Mukus May 26 '21 at 02:39
7

Think of variables (e.g. foo) of reference types (e.g. List<T>) as holding object identifiers of the form "Object #24601". Suppose the statement foo = new List<int> {1,5,7,9}; causes foo to hold "Object #24601" (a list with four items). Then calling foo.Length will ask Object #24601 for its length, and it will respond 4, so foo.Length will equal 4.

If foo is passed to a method without using ref, that method might make changes to Object #24601. As a consequence of such changes, foo.Length might no longer equal 4. The method itself, however, will be unable to change foo, which will continue to hold "Object #24601".

Passing foo as a ref parameter will allow the called method to make changes not just to Object #24601, but also to foo itself. The method might create a new Object #8675309 and store a reference to that in foo. If it does so, foo would no longer hold "Object #24601", but instead "Object #8675309".

In practice, reference-type variables don't hold strings of the form "Object #8675309"; they don't even hold anything that can be meaningfully converted into a number. Even though each reference-type variable will hold some bit pattern, there is no fixed relationship between the bit patterns stored in such variables and the objects they identify. There is no way code could extract information from an object or a reference to it, and later determine whether another reference identified the same object, unless the code either held or knew of a reference that identified the original object.

David Klempfner
  • 6,679
  • 15
  • 47
  • 102
supercat
  • 69,493
  • 7
  • 143
  • 184
  • Don't reference type variables hold `IntPtr`s? Couldn't you do `IntPtr.ToString()` to get the memory address? – David Klempfner Apr 18 '21 at 10:19
  • @DavidKlempfner: The .NET runtime needs to know at every point during program execution of at least one reference to every pinned object, and every reference to every unpinned object. By my understanding, if one passes an object field as a `ref` parameter, the system will keep track of what parts of the stack frame hold `ref` parameters, as well as references to the objects whose fields are accessed in such fashion; in at least some versions of the .NET gc. the it's possible for the system to relocate an object whose field is identified by a `byref`, and update the `byref` appropriately. – supercat Apr 19 '21 at 15:26
  • @DavidKlempfner: I think it's possible to pin an object to which a byref is held, and then convert the byref to an `IntPtr` that would remain valid as long as the object is pinned, but knowledge of an object's address at some point in time will only be meaningful if the object has been pinned continuously since the address was observed. – supercat Apr 19 '21 at 15:28
  • How did you learn all this? Do you recommend any textbooks? – David Klempfner Apr 19 '21 at 23:12
  • @DavidKlempfner: It's been ages since I read about how such things were done and did some experiments. The most important principle to understand is that if an object gets relocated, every reference that might ever be used to access that object will have the stored bit pattern updated to reflect the new location. A concurrent GC might set access-control bits so that an attempt to access an object at the old location would trigger a bus fault, and then have the bus fault handler update the address to reflect the new location, but the old storage would not be eligible for reclamation... – supercat Apr 20 '21 at 19:56
  • ...until all copies of the old address have been replaced with the new one. It's a system which would seem like it should be complicated and inefficient, but commonplace versions of both the JVM and .NET Runtime are able to use some clever techniques to make things work surprisingly well. – supercat Apr 20 '21 at 19:57
5

This is like passing a pointer to a pointer in C. In .NET this will allow you to change what the original T refers to, personally though I think if you are doing that in .NET you have probably got a design issue!

4

By using the ref keyword with reference types you are effectively passing a reference to the reference. In many ways it's the same as using the out keyword but with the minor difference that there's no guarantee that the method will actually assign anything to the ref'ed parameter.

Isak Savo
  • 32,569
  • 10
  • 58
  • 90
3

ref mimics (or behaves) as a global area just for two scopes:

  • Caller
  • Callee.
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
guneysus
  • 5,360
  • 2
  • 36
  • 35
1

If you're passing a value, however, things are different. You can force a value to be passed by reference. This allows you to pass an integer to a method, for example, and have the method modify the integer on your behalf.

Andrew
  • 11,520
  • 12
  • 65
  • 82
  • 5
    Whether you're passing a reference or a value type value, the default behaviour is to pass by value. You just need to understand that with reference types, the value you're passing *is* a reference. This isn't the same as passing *by* reference. – Jon Skeet Oct 09 '08 at 12:04
1

Ref denotes whether the function can get its hands on the object itself, or only on its value.

Passing by reference is not bound to a language; it's a parameter binding strategy next to pass-by-value, pass by name, pass by need etc...

A sidenote: the class name TestRef is a hideously bad choice in this context ;).

xtofl
  • 38,207
  • 10
  • 95
  • 177