When is using the C# ref keyword ever a good idea?

Question

The more I see ref used in production code, the more misuse I encounter and the more pain it causes me. I have come to hate this keyword, because from a framework-building standpoint, it seems silly. When would it be a good idea to communicate to users of your code the notion of maybe changing an object reference/value out from beneath them?

By contrast, I love out keywords and I love even more when no keywords are used at all, in both cases because of the guarantees you're given when using them. Ref on the other hand makes no guarantees, except that you'll be forced to initialize the parameter before you pass it in, even though nothing may be changed about it.

I'm no sage developer though; I'm sure it's got practically applicable uses. I'd just like to know what they are.

Answer 1

I'm using ref quite often. Just think about functions with multiple return values. It doesn't make sense to create a return object (helper object) or even using hashtables for this purpose.

Example:

 getTreeNodeValues(ref selectedValue, ref selectedText);

Edit:

It's better to use out here - as commented.

 getTreeNodeValues(out selectedValue, out selectedText);

I'm using it for processing objects:

MyCar car = new MyCar { Name="TestCar"; Wieght=1000; }

UpdateWeight(ref car, 2000);

Answer 2

Any time you want to change the value of a value type - this happens a lot in cases where you want to efficiently update a pair of related values (i.e. rather than returning a struct containing two ints, you pass (ref int x, ref int y))

Answer 3

The Framework Design Guidelines (a book by Krzysztof Cwalina and Brad Abrams) recommend to avoid both ref and out parameters.

AVOID using out or ref parameters.

Using out or ref parameters requires experience with pointers, understanding how value types and reference types differ, and handling methods with multiple return values. Also, the difference between out and ref parameters is not widely understood. Framework architects designing for a general audience should not expect users to master working with out or ref parameters.

The Framework Design Guidelines cite the canonical Swap method as a valid exception:

void Swap<T>(ref T obj1, ref T obj2)
{
    T temp = obj1;
    obj1 = obj2;
    obj2 = temp;
}

but at the same time a comment remarks

Swap always comes up in these discussions, but I have not written code that actually needed a swap method since college. Unless you've got a very good reason, avoid out and ref altogether.

Answer 4

It's useful when you need efficient in-place algorithms on bignums.

Answer 5

Maybe when you have a struct (which is a value type):

struct Foo
{
    int i;

    public void Test()
    {
        i++;
    }
}

static void update(ref Foo foo)
{
    foo.Test();
}

and

Foo b = new Foo();
update(ref b);

Here you would to use two-parameters with out like:

static void update(Foo foo, out Foo outFoo) //Yes I know you could return one foo instead of a out but look below
{
    foo.Test();

    outFoo = foo;
}

imaging the method having more than one Foo then you would get twice the parameters with out versus ref. An alternative is to return a N-tuple. I don't have a real-world example on when to use this stuff.

Add on: Different .TryParse methods could also have avoided out if they returned Nullable<T> instead which essentially is a tuple of boolean * T.

Answer 6

I try to avoid it on public APIs, but it definitely has uses. Mutable value-types is an important one, especially on things like CF (where mutable structs are more common, due to platform requirements). However, perhaps the most common time I use it is when refactoring parts of a complex algorithm out into a few methods, where a state object is overkill and I need to pass multiple values around:

i.e.

var x = .....
var y = .....
// some local code...
var z = DoSomethingSpecific(ref x, ref y); // needs and updates x/y
// more local code...

etc. Where DoSomethingSpecific is a private method, just moved out to keep method responsibility manageable.

Answer 7

Most of the Interlocked methods use ref parameters for (I’m sure you agree) good reason.

Answer 8

I have an example of a situation where - in my eyes - ref provides the cleanest solution:
In one of my projects I make rather extensive use of filters for the optional modification of some data... So basically I have an Interface IFilter<T> with T being the type of object to be filtered, which all my various filter classes implement. My IFilter<T> only has one method: void Filter(ref T element). My only alternative would be to have a function T Filter(T element). However, it is completely up to the implementation to decide whether to modify an existing object or to create a new one. Consequently ref is the cleanest approach.

Answer 9

Hypothetically, I'd guess that you might use a lot of ref/out arguments if you intended to mimic the architecture of older procedural software, for example old game engines and so on. I've scanned the source code of one, I think it was Duke Nukem 3D, and it's procedural with lots of subroutines modifying variables in place, and almost no functions. Obviously, you'd be unlikely to program like this for a real production application unless you had some specific aim in mind.

Answer 10

How about if one wishes to pass an array to a function which might or might not change its size and do something else to it. Often, one would wrap the array in another object, but if one wishes to handle the array directly passing by reference would seem the most natural approach.

Answer 11

I use ref in a current project when passing COM objects around because I don't want a new COM object implicitly created by the callee. My approach is that any method that creates an COM object is responsible for properly releasing it. From what I understand, doing COM interop can have nasty side effects when COM objects aren't properly released.