Why I need to use ref keyword in both declaration and Call?
Question
Duplicate of: What is the purpose of the “out” keyword at the caller?
Why I need to use 'ref' keyword in both declaration and Call.
void foo(ref int i)
{
}
For example, Consider above function. If I will call it without ref keyword as
foo(k);
it will give me error :
Argument '1' must be passed with the 'ref' keyword
Why isn't it enough to just specify in the method signature only ?
Solution
This is because ref
indicates that the parameter should be passed in by reference. It is something like pointer in C++
For example;
void CalFoo()
{
var i=10;
foo(ref i); //i=11
}
void foo(ref int i)
{
i++;
}
but
void CalFoo()
{
var i=10;
foo(i); //i=10
}
void foo(int i)
{
i++;
}
I think you can have both foo(ref int)
and foo(int)
in one single class. So if you don't specify the ref
.. how does the compiler knows which one to call?
OTHER TIPS
It enhances readability/understandability: When you look at the method call, you know that the ref value might change.
(As mentioned, this is a dupe of this question.)
For one thing, it's used as part of method overloading:
public void Foo(string x) { ... }
public void Foo(ref string x) { ... }
...
string x = "";
Foo(x); // Which should be used if you didn't have to specify ref?
Now one answer could be to prohibit that sort of overloading... but I think it's a good thing for C# to require this at the caller's side as documentation:
- The behaviour changes significantly when you use
ref
(orout
) - By calling out the rare uses of ref/out, it means you never need to check whether the argument is being passed by value or reference
- It also affects what you can pass (e.g. you can't pass a literal, or the result of a method call). This is clearer when it's explicit.
Note that C# 4 does allow implicit use of ref
for COM methods as there are so many ref
parameters which don't really have ref
behaviour (or at least, they don't take advantage of it). In such cases the compiler introduces a new local variable so that from the caller's point of view the argument really is being passed by value:
ComMethod(x);
translates into:
MyType tmp = x;
ComMethod (ref tmp);
This is a good compromise for COM methods, but I'm glad it's not the case for normal managed code.
As the Method and the Caller may be "far" away from each other (Different Assemblies, you may not even have the source of the one containing the method), having to specify out and ref explicitly helps making the intent clear. So it's something for the user so that they really know what they do, not a technical necessity.
While ref
could most of the time be inferred from the method signature, it's always obligatory due to the fact that it can change the behavior of the code after the method call completely. Consider:
string hello = "world";
MyMethod(ref hello);
Console.WriteLine(hello);
If the ref
keyword hadn't been there you would always expect the code to print out "world", while in reality, it can print anything.
I have also heard (or read somewhere - myaybe it was in an interview with the language designers) that the reason (like for many other "features" in C#) is to remind the programmer that the function he is giong to call use the argument by reference.