Re: Object references

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 03/22/05 

Date: Tue, 22 Mar 2005 22:56:55 -0000

Alex <response@myrealbox.com> wrote:
> > Um, I wrote that article. I definitely do understand what it says. If
> > you're claiming to agree with the article and still maintain that C#'s
> > behaviour is "the same as saying that the object itself is passed by
> > reference" then you're the one who doesn't understand the article, I'm
> > afraid.
>
> Maybe I don't.
>
> Would you be so kind to explain the difference between the following statements:
>
> 1) Object X is passed to function F by reference.
> 2) A reference to Object X is passed to function F by value.

Sure. Changing the value of the actual parameter in the function F has
no effect (as far as the caller sees) in the second case, but changes
the value of the formal parameter in the first case.
 
> I claim that the statements are equivalent, as they both describe
> putting a reference to object X on the stack (or a register,
> whatever) before calling function F. The difference is semantic but
> it can help visualize what is going on.
>
> If you think that I am mistaken, please show me how.

See above.

> Your article, as I understand it, talks about two different types of
> objects - a value object that is passed by reference and a reference
> object that is passed by value. In that case the behaviour that you
> are trying to show is indeed different but that is something
> different altogether.

While there are value types and reference types in .NET, it doesn't
really alter anything. If you pass something by value, then changing
the value which is passed doesn't affect the caller's value. If you
pass something by reference, the variable used by the called method is
the same variable (or l-value, whatever) as the caller is using -
changing one changes the other.

> > Not really. If you think it is, maybe I should change the article to
> > make it clearer. Passing an object itself by any means isn't possible
> > in .NET, as no expression has a type which is the object itself.
>
> My mistake. I was using generic English terms and not specific .NET terminology.
> If I replace "object" with "entity" will you agree with my statement then?

Nope, because it's the "pass by reference" which has a very specific
meaning. By claiming that objects are passed by reference, you're
implying semantics which just don't occur in .NET.

> > Pass by reference has a very specific meaning in terms of formal and
> > actual parameters, and is different to passing a reference by value -
> > in the same way as C doesn't have pass-by-reference at all, but that
> > doesn't stop you from passing pointers (by value).
>
> Actually, passing a pointer in C is equivalent to "pass by reference".

No it's not - that's the point. It's not the same thing in the strict
sense of the terminology, which means that if you tell people who *do*
know the strict sense of the terminology that objects are passed by
reference, they'll expect behaviour other than what they get.

Many of the uses of pass by reference can be simulated by passing an
address/reference/pointer/whatever by value, but it's not the same as
pass by reference in itself.

> And the actual behaviour is pretty close to your example:
> Passing a pointer to a data type (I'm being careful not to say
> "object") allows you to change the value if that data type from
> inside the function, but *not* to "re-seat" the pointer (make it
> point to a different instance of that data type.

Changing the value of the pointer (the parameter) doesn't change the
caller's value though - it's only changing the value of what the
pointer points at that makes the change visible. The parameter here is
the pointer, not the value of the variable whose address is passed as a
pointer.

> The same principle holds with C++ references.

I don't like to use C++ terminology as I don't know it well enough to
be confident of being strictly correct.

> C# (and, if I recall correctly, Java) confuses matters a bit by only
> allowing "reference types" to reside on the heap and "value types" on
> the stack but there is no fundamental difference in behaviour.

Even that's not true, as value types also reside on the heap within
reference type objects. Anyway...

See http://www.yoda.arachsys.com/java/passing.html for another way of
putting things. 

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Relevant Pages

  • Re: Question on LSP
    ... Sure, the developer must keep track of which type has been assigned to each pointer to manage complexity in creating the design, which is why the 'T' is in T*. ... Subtyping is a relation which does not ... Those object types are completely orthogonal to the semantics of being an object reference. ... aggregate references, is the aggregate of referenced objects or target ...
    (comp.object)
  • Re: Question on LSP
    ... Because construction paradigms have different goals. ... But that has nothing to do with what a pointer type ... But that does not mean that the semantics of an object reference is ... aggregate references, is the aggregate of referenced objects or target ...
    (comp.object)
  • Re: Modifying Class Object
    ... Before I start, note we're talking about semantics, not ... For example, as I used as reference in my first posting, the Java language spec. ... A pointer stores a reference to something. ...
    (comp.lang.python)
  • Re: Question on LSP
    ... equivalent addresses in the same context. ... Note that the language allows us to use a name like 'T' on the reference as a mnemonic so that the developer can keep track of what is happening with the indirection. ... Modern languages have proper pointer types. ...
    (comp.object)
  • Re: Nothing Keyword Destories Objects rather than just resetting the variable to an empty variable
    ... there is no difference between using ByVal or ByRef. ... as the C1 pointer was the sole reference to the class object. ... Yes, an object variable is a pointer to an object, but that is the only ... the keyword "NOTHING" should only destroy the ...
    (microsoft.public.excel.programming)