C# WPF reference passage function

Question

5.00/5 (1 vote)

See more:

OK this is something not related with WPF but on the basis of C#. I knew that classes are ALWAYS passed by reference differently from structs that are passed by value.

If you take a look at the following code you can see that I call a function with no REF keyword (supposedly there's no need for it since Paths is a class and therefore it should be always automatically called by ref with no need for the ref keyword)

C#

public MainWindow()
{
    InitializeComponent();
    Func(myPath);
    if(myPath==null)
       MessageBox.Show("AAAARGH");
}

Path myPath;

private void Func(Path p)
{
    if (p == null)
        p = new Path();
}

so after the function call, I'd expect my path not to be null anymore since it has been initialized in Func and then but that's not true. Ok I'm working on a global value, is that changing something?

Posted 28-Sep-15 4:35am

Patrick70__

Add a Solution

2 solutions

Solution 1

An Object if passed as a value type then changes made to the members of the object inside the method are impacted outside the method also. But if the object itself is set to another object or reinitialized then it will not be reflected outside the method.

So you need to use "ref" keyword or simply return the "new Path()" back!

Posted 28-Sep-15 5:04am

Leo Chapiro

Comments

[no name] 28-Sep-15 11:46am

Well, I like your answer and so a 5. For OP I think still hard to understand the parts "between" the lines.

Sergey Alexandrovich Kryukov 28-Sep-15 12:58pm

I agree. I this novice was me, I hardly could understand it. I suggested a bit more detailed answer, Solution 2. Maybe it also need some additional explanations, perhaps with illustrating code. Let's see what out inquirer says.
—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-09-28T06:56:00

Solution 2

You need to understand the following: parameters are passed by references only if ref or out is specified. So, your statement is incorrect: the objects, even the objects (instances) of classes are passed be value in all other cases. You just need to understand what it means.

Still, the class instances passes by value behave as if they were passed by reference: you can modify the instance inside a method and have it modified on exit. The same state for all other by-reference types, such as arrays. Why? This is because you really pass the variable or some other type's member to the method. And such objects are really pairs of object: the object itself and the reference to it. In C#, you cannot operate reference-type objects directly, you always do it through a reference. And a reference is passed to a method by value.

Finally, in nearly all cases, there is no point of passing a reference-type object by references. This is not prohibited, but rarely can make sense. If you really want to return a reference to some object which has been created inside the method, or if you replace some passed reference by another reference, consider using methods' return values.

See also my past answer on the nature of reference-type objects: Equivalent of 'C' pointer in c#.[^].

I hope you can draw the conclusions.

—SA

Posted 28-Sep-15 6:56am

Sergey Alexandrovich Kryukov

Updated 28-Sep-15 7:03am

v2

Comments

[no name] 28-Sep-15 13:30pm

A 5. I really have to admit, that these things also make me headache...especially when I need to explain it in an intuitive way. And no it does not mean your Explanation is easy, but it is technical correct ;)
Bruno

Sergey Alexandrovich Kryukov 28-Sep-15 13:45pm

Thank you, Bruno. I think things can be explained by going into the fine detail.
—SA

Patrick70__ 30-Sep-15 6:09am

Thanx Sergey for the clarification. So to put it in a nutshell the behaviour I talked about is correct but the reasons were incorrect. Now I know why. Thanx!!

Sergey Alexandrovich Kryukov 30-Sep-15 16:43pm

You are very welcome.
—SA

Patrick70__ 30-Sep-15 6:11am

One more question: you said that it RARELY makes sense passing a reference type by REF. In my book this NEVER makes sense. Could you elaborate a case in which there's point in doing this?
Thanx

Sergey Alexandrovich Kryukov 30-Sep-15 16:51pm

Sure.
As I say, you can modify the reference itself inside the method and pass it back to ref or out parameter. You can return it in return value, but it can be already used for returning another piece of information.

This just one example of .NET FCL method where this is the case: System.Collections.Generic.Dictionary<tkey, tvalue="">.TryGetValue</tkey,>:
https://msdn.microsoft.com/en-us/library/bb347013%28v=vs.110%29.aspx.

When your generic actual type TValue is a reference type (most typical usage case), you return reference by reference via the second parameter out TValue value. Method return is used to indicate that a value was found, or not (then it cannot be used). The authors of the library could have returned some structure with both Boolean and TValue objects, but the current form of the method is probably simpler (for those who understand what it does :-), so I would say this decision makes sense.

So, really, "rarely" means "makes sense in some rare cases".

—SA

Patrick70__ 2-Oct-15 18:01pm

Thanx again very clear and concise.

Sergey Alexandrovich Kryukov 2-Oct-15 20:18pm

You are welcome. :-)
—SA