please help me understand ref and out

  • Thread starter Thread starter Bradley1234
  • Start date Start date
B

Bradley1234

Typically when passing by reference you point to the location of the
variable, and can modify the original

When passing by value, you include a disposable copy of the variable, but it
protects the original.

The "ref" keyword lets you write as if passing by value, but it does the
work of passing by refence for you?

The "out" keyword appears to do the same thing, reading the C# spec has not
shown me the main difference, is there a difference? or does the out keyword
just stomp on whatever the value was with a new value, then goes ahead?
 
Okay, after I ask... using the OUT keyword appears to force the compiler to
expect the method to modify that variable, or it wont compile
 
Bradley1234 said:
Typically when passing by reference you point to the location of the
variable, and can modify the original

When passing by value, you include a disposable copy of the variable, but it
protects the original.

The "ref" keyword lets you write as if passing by value, but it does the
work of passing by refence for you?

The "out" keyword appears to do the same thing, reading the C# spec has not
shown me the main difference, is there a difference? or does the out keyword
just stomp on whatever the value was with a new value, then goes ahead?

See http://www.pobox.com/~skeet/csharp/parameters.html
 
Use "out" and it has to be initialized on the way back out of the call, i.e.
*by* the callee. It guarantees that when the method returns, there will
definitely be *some* value assigned to it, when there wasn't necessarily
before the function was called.

Use "ref" it has to be initialized *both* ways, on the way in *and* on the
way out. But since it isn't going to become uninitialized by the function,
this effectively means it just has to be initialized by the caller. The
callee doesn't have to assign anything to it if it doesn't want to, because
it knows it is already assigned.

Note that with "out" the called function isn't allowed to read the value
either until it's assigned something to it.
Note also that due to the above, "out" only requires half the amount of
marshalling as "ref" and is thus faster.
 
Thanks Bonj, it makes sense until this part,
Use "ref" it has to be initialized *both* ways, on the way in *and* on the
way out. But since it isn't going to become uninitialized by the function,
this effectively means it just has to be initialized by the caller. The
callee doesn't have to assign anything to it if it doesn't want to, because
it knows it is already assigned.

So I understand ref must be used with a variable that was already
initialized, but you said "*and* on the way out" ?

But then the callee doesnt have to assign anything to it, I tried sample
code and noticed this, it doesnt care if it gets assigned or not.

I was hoping this was a useful shortcut for having to deal with pointers,
this looks like an awesome feature.

And thanks, Jon for that webpage, Ill reference that and add a bookmark
 
"out" is a more specific form of "ref". By giving the compiler more
information you allow it to make more checks for you. By designating a
parameter as "out" you are telling the compiler, "I guarantee that when
this method returns, this argument will have been set to a value by the
method."

The compiler then does the necessary static checking to ensure that
your method is living up to its contract.

"ref" is more vague: it states that the method may or may not choose to
assign a (new) value to the variable.

You should use "out" whenever your design calls for multiple return
values from a method, because you then get "free" code correctness
checking. It is much less often that you need "ref". If you just use
"ref" all over the place the compiler won't care, but then you give up
the opportunity to find bugs at compile time rather than at run time.
 
Back
Top