When to use ref and when it is not necessary in C#

Question

I have a object that is my in memory state of the program and also have some other worker functions that I pass the object to to modify the state. I have been passing it by ref to the worker functions. However I came across the following function.

byte[] received_s = new byte[2048];
IPEndPoint tmpIpEndPoint = new IPEndPoint(IPAddress.Any, UdpPort_msg);
EndPoint remoteEP = (tmpIpEndPoint);

int sz = soUdp_msg.ReceiveFrom(received_s, ref remoteEP); 

It confuses me because both received_s and remoteEP are returning stuff from the function. Why does remoteEP need a ref and received_s does not?

I am also a c programmer so I am having a problem getting pointers out of my head.

Edit: It looks like that objects in C# are pointers to the object under the hood. So when you pass an object to a function you can then modify the object contents through the pointer and the only thing passed to the function is the pointer to the object so the object itself is not being copied. You use ref or out if you want to be able to switch out or create a new object in the function which is like a double pointer.

Answer 1

Short answer: read my article on argument passing.

Long answer: when a reference type parameter is passed by value, only the reference is passed, not a copy of the object. This is like passing a pointer (by value) in C or C++. Changes to the value of the parameter itself won't be seen by the caller, but changes in the object which the reference points to will be seen.

When a parameter (of any kind) is passed by reference, that means that any changes to the parameter are seen by the caller - changes to the parameter are changes to the variable.

The article explains all of this in more detail, of course :)

Useful answer: you almost never need to use ref/out. It's basically a way of getting another return value, and should usually be avoided precisely because it means the method's probably trying to do too much. That's not always the case (TryParse etc are the canonical examples of reasonable use of out) but using ref/out should be a relative rarity.

Answer 2

Think of a non-ref parameter as being a pointer, and a ref parameter as a double pointer. This helped me the most.

You should almost never pass values by ref. I suspect that if it wasn't for interop concerns, the .Net team would never have included it in the original specification. The OO way of dealing with most problem that ref parameters solve is to:

For multiple return values

• Create structs that represent the multiple return values

For primitives that change in a method as the result of the method call (method has side-effects on primitive parameters)

• Implement the method in an object as an instance method and manipulate the object's state (not the parameters) as part of the method call
• Use the multiple return value solution and merge the return values to your state
• Create an object that contains state that can be manipulated by a method and pass that object as the parameter, and not the primitives themselves.

Answer 3

You could probably write an entire C# app and never pass any objects/structs by ref.

I had a professor who told me this:

The only place you'd use refs is where you either:

1. Want to pass a large object (ie, the objects/struct has objects/structs inside it to multiple levels) and copying it would be expensive and
2. You are calling a Framework, Windows API or other API that requires it.

Don't do it just because you can. You can get bit in the ass by some nasty bugs if you start changing the values in a param and aren't paying attention.

I agree with his advice, and in my five plus years since school, I've never had a need for it outside of calling the Framework or Windows API.

Answer 4

Since received_s is an array, you're passing a pointer to that array. The function manipulates that existing data in place, not changing the underlying location or pointer. The ref keyword signifies that you're passing the actual pointer to the location and updating that pointer in the outside function, so the value in the outside function will change.

E.g. the byte array is a pointer to the same memory before and after, the memory has just been updated.

The Endpoint reference is actually updating the pointer to the Endpoint in the outside function to a new instance generated inside the function.

Answer 5

Think of a ref as meaning you are passing a pointer by reference. Not using a ref means you are passing a pointer by value.

Better yet, ignore what I just said (it's probably misleading, especially with value types) and read This MSDN page.

Answer 6

my understanding is that all objects derived from Object class are passed as pointers whereas ordinary types (int, struct) are not passed as pointers and require ref. I am nor sure about string (is it ultimately derived from Object class ?)

Answer 7

While I agree with Jon Skeet's answer overall and some of the other answers, there is a use case for using ref, and that is for tightening up performance optimizations. It has been observed during performance profiling that setting the return value of a method has slight performance implications, whereas using ref as an argument whereby the return value is populated into that parameter results in this slight bottleneck being removed.

This is really only useful where optimization efforts are taken to extreme levels, sacrificing readability and perhaps testability and maintainability for saving milliseconds or perhaps split-milliseconds.

Answer 8

Ground zero rule first, Primitives are passed by value(stack) and Non-Primitive by reference(Heap) in the context of TYPES involved.

Parameters involved are passed by Value by default. Good post which explain things in details. http://yoda.arachsys.com/csharp/parameters.html

Student myStudent = new Student {Name="A",RollNo=1};

ChangeName(myStudent);

static void ChangeName(Student s1)
{
  s1.Name = "Z"; // myStudent.Name will also change from A to Z
                // {AS s1 and myStudent both refers to same Heap(Memory)
                //Student being the non-Primitive type
}

ChangeNameVersion2(ref myStudent);
static void ChangeNameVersion2(ref Student s1)
{
  s1.Name = "Z"; // Not any difference {same as **ChangeName**}
}

static void ChangeNameVersion3(ref Student s1)
{
    s1 = new Student{Name="Champ"};

    // reference(myStudent) will also point toward this new Object having new memory
    // previous mystudent memory will be released as it is not pointed by any object
}

We can say(with warning) Non-primitive types are nothing but Pointers And when we pass them by ref we can say we are passing Double Pointer