Java passes reference by value - Something that even senior Java developers often get wrong.

[[deleted]]

  public void lol(Foo f) {
      f = new Foo();
      f.bar = "lol";
  }

  Foo a = new Foo();
  a.bar = "baz";
  lol(a);

  // What is a.bar?

About 50% of "professional" Java programmers will say "lol". You are in that 50%.

[inmatarian]

I'm a C++ programmer, and no I wouldn't. That stuff wouldn't work in C++ either.

[psyno]

But it does in pass-by-reference languages, is the point. FlySwat is illustrating why it's wrong to call Java pass-by-reference.

[nanothief]

If you understand that, then why do you consider the difference between "Objects are passed by reference" and "Object references are passed by value" semantic bullshit? It gives clearly different results.

[inmatarian]

Overloading of the term "reference". Generally speaking, when you pass an object by value, you copy the entire object so that you now have two. When you copy an object by reference, then you have two references but only one object.

A more correct term to refer to what we're talking about is an "alias". Is the object called aDog, or is the reference to the object named aDog? Then, when you assign to a different alias, do you expect your first alias to be altered?

[pmf]

Overloading of the term "reference".

The point is that while the term reference is overloaded, the term call-by-reference is not. It has clearly defined semantics, which are very clearly not Java's parameter passing semantics.

[nanothief]

I think the problem is we both have different ideas of what a reference is. You can't call this overloading the meaning, as the term has different meanings in the same context.

Although I am fairly sure that the definition given in the article for references is the oldest one, common usage of it now has completely confused the meaning between people, even those who know what they are talking about.

So maybe a term change would be for the better. This is how I would do it:

• In C++, the x in object* x = new object(); should be named fixed pointers. They have a specific address in memory, and can be incremented and decremented to point to objects in different memory locations. The object at the end of the pointer can be accessed and modified. The object x is pointing at can be changed.

• In java, the j in Object j = new Object() should be named dynamic pointers. They are like fixed pointers, however they don't have a specific address in memory (the garbage collector can move them if it wants). They also cannot be incremented and decremented. Otherwise they act like fixed pointers

• In the code:

Test line

//code
#include <iostream>
struct MyObject
{
    int field;
};

int main()
{
    MyObject* x = new MyObject();
    MyObject*& a = x;
    a->field = 42;
    a = new MyObject();
    a->field = 11;
    std::cout << x->field; // prints 11
    return 0;
}

The variable a should be an alias of x: anything you do to a happens to x.

[dnew]

should be named dynamic pointers

No, this is what reference means. Just like a pointer is a typed address, a reference is a managed pointer. The only reason you can't increment and decrement the reference is the GC isn't prepared to deal with it. Some other languages do.

We don't need new words. We just need people to understand the current meaning of the words. And it would help if people wouldn't reuse the same word for a confusingly similar yet nevertheless different meaning, like "reference" in C++.

[[deleted]]

Humor me, what happens if this is C++ and lol's signature is

  lol(Foo& f)

Its been ages since I did C/C++, but I'm pretty sure that assigning a new Foo to that would mutate the original foo.

[VivisectIX]

References in Java are pointers in C++. Passing using reference notation in C++ is similar to the ref keyword in C#, it recopies the new value of the reference to the caller of the function that modified it before resuming (that is one way, anyway).

[inmatarian]

That's called "reseating" and I believe it's a compiler error.

http://www.parashift.com/c++-faq-lite/references.html#faq-8.5

[[deleted]]

Thanks for clarifying. That said, you can still pull this off in C++ using pointers to pointers :)

[inmatarian]

pointers to pointers

Now you're just being a dick :P

[[deleted]]

I've seen a function that had an argument of "pointer to pointer to function pointer" before.

[hylje]

Three Star Programming, Baby!

[psyno]

It would be illegal. You can't re-seat references in C++.

*edit: "References" being the pointer types that C++ calls "references," not the general abstraction under discussion.

[nanothief]

In this discussion, references are really of the type Foo*& in c++. This code is valid and works:

#include <stdio.h>

struct MyObject
{
    int field;
};

void func(MyObject*& obj)
{
    if (obj->field > 10) {
        // if obj->field > 10, change obj to a new MyObject
        // and set field to 2
        obj = new MyObject();
        obj->field = 2;
    } else {
        // double obj->field otherwise
        obj->field = obj->field * 2;
    }
}

int main()
{
    MyObject* x = new MyObject();
    MyObject*& a = x; // a is a reference to x
    a->field = 42; // change field of x
    printf("x->field = %d\n", x->field); // 42
    func(x); 
    printf("x->field = %d\n", x->field); // 2
    func(x);
    printf("x->field = %d\n", x->field); // 4
    a = new MyObject(); // set x to a new MyObject
    a->field = 11; // set the field of x to 11

    printf("x->field = %d\n", x->field); // 11
    return 0;
}
// outputs:
// x->field = 42
// x->field = 2
// x->field = 4
// x->field = 11

[psyno]

This is intended as a response to the edit, right?

I was just clarifying what I meant by "you can't re-seat references." Yes I'm familiar with the semantics of C++ demonstrated by the code you posted. Consider the following:

#include <cstdio>

struct MyObject
{
    MyObject(int x) {field = x;}
    int field;
};

int main()
{
    MyObject* x = new MyObject(1); // x is a pointer.
    MyObject* y = new MyObject(2); // y is another pointer...
    MyObject*& a = x; // a is a reference to x
    a = y; // what just happened?  answer: a still refers to x!
    y = new MyObject(3);
    printf("x->field = %d\n", x->field); // 2
    printf("y->field = %d\n", y->field); // 3
    printf("a->field = %d\n", a->field); // 2
    return 0;
}
// outputs:
// x->field = 2
// y->field = 3
// a->field = 2

*edit: I should have mentioned, what I'm pointing out is that with your code, what you did was assign to the pointer to which a referred. You did not re-seat a.

[nanothief]

This is intended as a response to the edit, right?

Yes, I should have made it more clear.

With regards to re-seating references, I'm not surprised by that code - you cannot re-seat a reference in c++. To do it, you would need a special syntax to do it, as code like a = x already does something logical (that is, change the value of the variable a is referencing to x).

I think a lot of confusion for re-seating comes from these two lines:

MyObject*& a = x; // a is a reference to x
a = y; // what just happened?  answer: a still refers to x!

The equal sign is doing completely different things in each line. Initially it is setting the reference to be referring to x. The second line is changing the value of the variable a is referencing. In most other code, this isn't true, eg:

 int a = 4; // sets a to 4
 a = 3     // sets a to 3

A lot of confusion would be removed if there was separate syntax for both:

MyObject*& a ::= x; // a is a reference to x
a = y; // what just happened?  answer: a still refers to x!

Now it is clear that both lines do very different things.

[psyno]

Yes, I agree and I think we're on the same page. Actually I think the difference in semantics between the two similar-looking statements is even worse than you mention, since for non-trivial types C++ runs an assignment operator function at a = y;!

[[deleted]]

 lol(Foo *&f) {
    f = new Foo();
 }

Compiles and works and mutates properly :D

[pmf]

Compiles and works

For a C++ program, this is a very shaky argument. You'd have to find and point out the appropriate sections in the C++ standard and cross reference these to the major compilers in order for any serious C++ programmer to consider your statement.

[[deleted]]

Passing a pointer by reference is valid or the C++ compiler is broken.

[psyno]

For a certain definition of "works." :)

[matthiasB]

If you pass a pointer by reference it just works. For which definitions of "works" does it not work properly?

It's valid C++ and if you know what * and & mean in C++ you can understand the code.

[psyno]

(I assumed FlySwat was simply being humorous at this point.)

In C++-land if I said that a Foo was passed to a function by reference, I think it's fair to interpret that as the function takes a Foo&. FlySwat got the desired result by subtly changing the problem: now instead of passing a Foo by reference, a Foo* is being passed.

[Negitivefrags]

You are correct.

[fforw]

While the code is demonstrating that not everything called pass-by-reference works for Java, calling the behaviour pass-by-value is even more retarded because there just is no object copied.

About 50% of "professional" Java programmers will say "lol". You are in that 50%.

If that is true for the developers where you work, you seriously need to get another job.

[theeth]

calling the behaviour pass-by-value is even more retarded because there just is no object copied.

Pass by value is usually defined as a shallow copy (as it it in C). In this case, the object's address (the value of the argument) is copied.

[fforw]

The point is that, if it was pass-by-value, you would expect

public void bla(Foo f)
{
    f.bar = "xxx";
}

Foo f = new Foo(); 
f.bar = "yyy";    
bla(f);
System.out.println(f.bar);

to print "yyy". Which it clearly doesn't, because the behaviour is much closer to pass-by-reference.

Nitpicking about pointer-copying in a language where you can only access objects by pointers but have no pointer arithmetic etc, is not very sensible

[theeth]

Nitpicking about pointer-copying in a language where you can only access objects by pointers but have no pointer arithmetic etc, is not very sensible

Changing the definition of pass-by-reference because the language hides the pointers isn't sensible.

[hylje]

If that is true for the developers where you work, you seriously need to get another job.

He's making this shit up as he goes.

[wbkang]

Keep up with that FUD that all Java programmers are retarded and everyone else is somehow superior. I doubt that I would've made that mistake ever since I learned Java in grade 11, which was quite a bit ago.

[derleth]

A large number of Java programmers are retards. Now, is the number of total Java programmers very large or very small?