no pointer in Java => my problem

[Roedy Green]

to me the reference is the Object

An ex-assembler person would never say that. A reference is about 32
bits -- a pointer. An object is a ruddy huge thing on a heap
somewhere full of data. They are quite different animals.

I suggest you avoid conflating them. You will not only end up
confusing yourself, you will spread confusion among the newbies.

 

[Roedy Green]

An ex-assembler person would never say that. A reference is about 32
bits -- a pointer. An object is a ruddy huge thing on a heap
somewhere full of data. They are quite different animals.

I suggest you avoid conflating them. You will not only end up
confusing yourself, you will spread confusion among the newbies.

In some languages you can pass either an object or a reference as a
parameter, not in java. You can only pass a reference.

When you pass an object, it makes a copy of the object and pushes the
giant thing to the stack. When you pass a reference, the pointer value
of the reference (about 32 bits) gets pushed to the stack. Your
pointer points to the original object.

In Java you never pass objects as parameters, just the VALUES of
references to objects.

 

[Lasse Reichstein Nielsen]

Says who?

Me, obviously

You can't pass an object by value in Java (you can't pass an
object at all in Java). But in C++ you can pass objects by value or by
reference. So in the world of programming langauages passing an object by
value does make sense.

Except (to me) an integral part of an object is its identity. You
don't pass the object itself. You make a copy and pass that. It is no
longer the same object, but a completely different object (although
its properties are the same). So you didn't pass the original object
by value.

So the analogy is not a perfect analogy, but I wouldn't say it
breaks down.

Perhaps "Breaks down" was too harsh. I think it is a very good analogy.

But it is still not pass-by-reference.

I think we agree here.

Pass by reference would allow the called method to change the binding
of a variable that is not in its scope. You can't do that in Java.

/L

 

[Chris Smith]

You have that backwards. The lvalue of the formal parameter is the same as
the lvalue of the actual parameter. The formal parameter is the variable
within the called code. In PBV it has a distinct lvalue from the actual
parameter and in PBR it has the same lvalue as the actual parameter.

How do they differ? Either the lvalues are the same, or they are
different. There's no distinction between "a is the same as b" versus
"b is the same as a".

I disagree with this notion of hidden versus non-hidden PBR. It makes no
sense given the definition of PBR.

What exactly do you disagree with about this? I'm contrasting C++ to a
language like (for example) C#, where you have to essentially declare
"yes, I know this is pass by reference", and if you don't then the
compiler gives an error message. They are both the same semantics,
except that in the latter case, you have to be clear with the compiler
that you are indeed intending those semantics.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

How do they differ? Either the lvalues are the same, or they are
different. There's no distinction between "a is the same as b" versus
"b is the same as a".

The difference is which one is the one that could vary. Your way sounds like
you are saying it is PBR because the language sets the lvalue of the actual
parameter to be the same as the lvalue of the formal parameter.

What exactly do you disagree with about this? I'm contrasting C++ to a
language like (for example) C#, where you have to essentially declare
"yes, I know this is pass by reference", and if you don't then the
compiler gives an error message. They are both the same semantics,
except that in the latter case, you have to be clear with the compiler
that you are indeed intending those semantics.

Consider if you called a method using foo( ref i ); The question is what is
the actual parameter to the method. Is the parameter i or is it the
expression "ref i"? We could probably debate it for some time. If we go with
the notion that the actual parameter is ref i then that expression has no
lvalue (at least to my knowledge but I'm not a C# expert). In my way of
thinking the parameter is the expression ref i which produces an rvalue
which is the lvalue of the expression i.

Consider also a similar thing in C. If I called foo( &i ) is the actual
parameter i or is it the expression &i? In this case &i has an lvalue but no
rvalue. I think you would be hard pressed to make a case for saying the
parameter is actually i. And I see little difference between the two.

I think before you talk about hidden and non-hidden pass by reference you
have to clarify your definitions of actual parameter. To call this pass by
reference to me is changing the established definition for what that means.
According to the book I use, "the expressions passed into those parameters
at the point of invocation are the actual parameters."

 

[Chris Uppal]

You are focussing on the reference when you should focus on variables. The
variable that contains the reference and the object that it references are
not the same thing. It is not true that the variable and the object are
the same thing in Java. What you passed in your example was a variable,
but more importantly the formal parameter for the method is also a
variable. Changing the value of the variable does not change the object.

Agreed. There is a variable in the caller holding the reference to the object.
The object itself may contain further variables. Those variables can be
changed by the called code, the variables in the caller cannot. A simple and
obvious distinction, to my mind.

-- chris

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

Its not just picky, its a technicality. To me the ArrayList is the
parameter. Yes you can seperate the concept of an object and its
reference but can you actually use an object without its reference in
java? There is only one way to access the Object and that is through
its reference, to me the reference is the Object. When we start
saying things like "no you aren't really passing something that can be
modified because the thing your passing isn't really the thing your
interested in, its the indirect reference to it", we end up confusing
people.

No not really. The confusion begins when you start using non-standard
terminology.

If we get picky, you can't really modify the parameter passed in C++
either, because you are really only passing the Address of something
not the thing itself. But you will say "Wait, in C++ we have
references thats different". Not really, it will probably be
implemented the same as though you passed an address.

This is not relevant. The semantics are relevant. See C++ FAQ lite on
references (they don't agree with you):

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

To illustrate
this point. Here are 2 C++ files that I output the assembly for. The
assembly is exactly the same, except for a directive saying the name
of the source file.


tuxedo@jabba:/tuxedo/bryanc/testc>cat test1.cpp

extern "C" void modify (int * i) {
*i=0;
}
tuxedo@jabba:/tuxedo/bryanc/testc>cat test2.cpp
extern "C" void modify (int & i) {
i=0;
}

This is a pretty bad example, and further illustrates your confusion. In
the first case, you are passing an int pointer by value, and in the
second case you are passing an int by reference.

A better example would be:

/*
* Pass pointer by value.
*/
void func(int *p)
{
*p = 0; // changes value pointed to by p
int j = 1;
p = &j; // changes value of pointer
// but only until the end of the function
}

/*
* Pass pointer by reference
*/
void func(int *&p)
{
*p = 0; // does the same thing as above
int j = 1;
p = &j; // changes the value of pointer permanently
// this is impossible with pass by value
// this is also a dangerous bug
}

Another example, using your examples as a model:

/*
* Pass by value (of pointer)
*/
void modify(int *p)
{
int q = 15;
p = &q; // p points to local q
*p = 20; // q is now 20. the value of
// the int that p pointed to originally was not changed
}

/*
* Pass by reference
*/
void modify(int &p)
{
int q = 15;
p = q; // oops! we overwrote the value of p
// there is no way to simulate PBV in PBR
// but the reverse is possible
}

 

[Bryan Castillo]

You are focussing on the reference when you should focus on variables. The
variable that contains the reference and the object that it references are
not the same thing. It is not true that the variable and the object are the
same thing in Java. What you passed in your example was a variable, but more
importantly the formal parameter for the method is also a variable. Changing
the value of the variable does not change the object.

I see now and it makes sense. I didn't really mean that the reference
is the object. I was really thinking that when you pass a reference
to a method you might as well be passing the object since that method
may perform operations which may modify the object. The object will
still be the same object you had before, just modified and the callee
can't actually make your reference in the caller refer to a different
object.

Sorry for being so obstinate.

 

[Timo Kinnunen]

Aside from that, a C++ pas-by-reference parameter looks identical to
passing by value, which is its own problem; I don't have an indication
that I'm passing by reference at all, hence I may not expect any change.

Well, perhaps it's passing objects by value which is at fault, because you
could easily pass by a reference to const instead and let the callee make a
non-const copy is she needs it.

 

[Dale King]

Except (to me) an integral part of an object is its identity. You
don't pass the object itself. You make a copy and pass that. It is no
longer the same object, but a completely different object (although
its properties are the same). So you didn't pass the original object
by value.

There are two different sets of semantics that can be applied to objects,
reference semantics and value semantics. Java only supports reference
semantics. Reference semantics are a requirement to support polymorphism.
C++ supports both. In value semantics identity is not important.

Pass by reference would allow the called method to change the binding
of a variable that is not in its scope. You can't do that in Java.

And that again is part of what is dangerous about pass by reference. The
called method can change variables that it doesn't own and it can do this
without the caller having any say so in the matter. C#'s addition of a ref
qualifier on the caller parameter to allow pass by reference makes it safer,
but in general I have not found any real need for pass by reference in Java.
There are usually much better solutions which are more appropriate and
easier to read. Many people coming from other languages have either not been
exposed to these methods or as is often the case they seem to have a phobia
of creating objects.

 

[sunder]

in reference to below:

StringBuffer g = new StringBuffer( "Hello" );

The variable g does not contain the string "Hello", it contains a
reference (or pointer) to an object instance that contains the
string
"hello".

if that is true then
import java.io.*;
import java.util.*;
public class Test //implements ITest
{
public static void main(String arg[])
{
String str = "Sunder Chitturi";
StringBuffer buffer = new StringBuffer(str);

str = "Utt chitturi";

System.out.println("value now:"+str);
System.out.println("value now:"+buffer.toString());
}
}

the result should be
value now:Utt chitturi
value now:utt Chitturi

its not , I dont think new StringBuffer(String ...) will have a
pointer to string , I think the contents of the string are copied.

 

[Sudsy]

sunder wrote:

the result should be
value now:Utt chitturi
value now:utt Chitturi

its not , I dont think new StringBuffer(String ...) will have a
pointer to string , I think the contents of the string are copied.

Why do you state that "result should be"? Anyone who's programmed
in Java understands that when you created the StringBuffer you did
so with the contents of the String passed to the constructor.
Did you presume that the StringBuffer automagically retained a
pointer (char * in C parlance) to the original string such that if
it changed then the StringBuffer would change contents also?

How about this C example?

#include <stdio.h>

main( int argc, char **argv ) {
char *sp1, *sp2;

sp1 = "x";
sp2 = sp1;
sp1 = "y";
printf( "sp1 = '%s', sp2 = '%s'\n", sp1, sp2 );
}

Would you expect the output to be this?

sp1 = 'y', sp2 = 'y'

Wake up and smell the coffee! Output (as expected, BTW) is this:

sp1 = 'y', sp2 = 'x'

Please think through the problem before arriving at deficient
suppositions.

 

[Chris Smith]

sunder wrote:


Why do you state that "result should be"? Anyone who's programmed
in Java understands that when you created the StringBuffer you did
so with the contents of the String passed to the constructor.

Yep. If you'd read sunder's post (and quoted a complete sentence) it'd
be clear that this was a counterexample to a flawed way of looking at
the situation. The sentence was something like "if you were to adopt
that flawed perspective, then this should produce such and such result".

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dale King]

in reference to below:

StringBuffer g = new StringBuffer( "Hello" );

The variable g does not contain the string "Hello", it contains a
reference (or pointer) to an object instance that contains the
string
"hello".

if that is true then
import java.io.*;
import java.util.*;
public class Test //implements ITest
{
public static void main(String arg[])
{
String str = "Sunder Chitturi";
StringBuffer buffer = new StringBuffer(str);

str = "Utt chitturi";

System.out.println("value now:"+str);
System.out.println("value now:"+buffer.toString());
}
}

the result should be
value now:Utt chitturi
value now:utt Chitturi

No, it shouldn't be for many different reasons. The str = "Utt chitturi";
line does not change the String object that str references it merely points
the str variable to point to another String object. On top of this String
objects are designed to be immutable so that you cannot change String
objects.

its not , I dont think new StringBuffer(String ...) will have a
pointer to string , I think the contents of the string are copied.

It's actually a little more complicated than that, but from a logical
viewpoint that is what happens. In reality it has some optimizations to
delay making a copy until it is needed.

 

[Chris Smith]

[Adding cross-post to C#. After all, there's no need to avoid
knowledgable people on this subject. As an introduction for C#
newsgroup people, Dale and I are discussing whether C# really has pass
by reference. The question boils down to whether the keyword "ref"
should be considered a part of the actual and formal parameters, or
simply part of the syntax.]

The difference is which one is the one that could vary. Your way sounds like
you are saying it is PBR because the language sets the lvalue of the actual
parameter to be the same as the lvalue of the formal parameter.

I see. I certainly didn't intend for it to sound that way. As far as I
can tell, we are in complete agreement here except for my debatably
confusing use of the English language.

Consider if you called a method using foo( ref i ); The question is what is
the actual parameter to the method. Is the parameter i or is it the
expression "ref i"? We could probably debate it for some time. If we go with
the notion that the actual parameter is ref i then that expression has no
lvalue (at least to my knowledge but I'm not a C# expert). In my way of
thinking the parameter is the expression ref i which produces an rvalue
which is the lvalue of the expression i.

Frankly, I think that's an incorrect way of looking at it. AFAIK (and
I'm no expert either, but...) there is no such thing in C# as an
expression "ref i". Although the Microsoft Press copy of the C# laguage
spec that I'm reading infuriatingly lacks an index (what were they
thinking?!?), it appears at first glance that the only uses of the ref
keyword are as a part of the grammars for the productions of "argument"
and "parameter-modifier" (which is used in "fixed-parameter"). The ref
keyword is not an operator that produces its own sort of expression.

So when you say:

I think before you talk about hidden and non-hidden pass by reference you
have to clarify your definitions of actual parameter. To call this pass by
reference to me is changing the established definition for what that means.
According to the book I use, "the expressions passed into those parameters
at the point of invocation are the actual parameters."

I think this is really just pushing the dispute onto a different word.
In C#, "ref i" isn't an expression, so the expression passed in at the
point of invocation must just be "i". I think there's definite good
reason for trusting the language spec's refusal to classify "ref i" as
an "expression" as well; namely, that it's illegal to use it in *any*
other context aside from a method invocation.

If there are other uses of 'ref i' which can obtain a pointer to some
variable (and there may be, as I'm definitely far from all-knowing about
C#), then I'd be wrong. But if, as I seem to be finding, "ref" is just
a required keyword that declares to the compiler that you know pass-by-
reference is happening, then I'd still call it pass-by-reference.

It's also interesting to read where section 1.3 discusses the subject
(and admittedly, it doesn't seem to be a normative piece of the
specification, nor is use of terms by the specification necessarily
consistent with their common usage, but nevertheless.) If you make some
simple replacements for clearer terminology:

"variable" -> "lvalue"
"parameter" -> "formal parameter"
"argument" -> "actual parameter"

Then this paragraph reads like the definition of pass by reference. As
far as I can tell, the only debatable replacement above is "variable" to
"lvalue"

Finally,

Consider also a similar thing in C. If I called foo( &i ) is the actual
parameter i or is it the expression &i? In this case &i has an lvalue but no
rvalue. I think you would be hard pressed to make a case for saying the
parameter is actually i. And I see little difference between the two.

Again, the difference here is that &i in C really is an expression.
That doesn't appear to be true for "ref i" in C#.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Jon Skeet [C# MVP]]

[Adding cross-post to C#. After all, there's no need to avoid
knowledgable people on this subject. As an introduction for C#
newsgroup people, Dale and I are discussing whether C# really has pass
by reference. The question boils down to whether the keyword "ref"
should be considered a part of the actual and formal parameters, or
simply part of the syntax.]

<snip>

Hi guys. Good to see you again

Finally,

Again, the difference here is that &i in C really is an expression.
That doesn't appear to be true for "ref i" in C#.

Indeed it's not.

I think it's reasonable to conclude that C# genuinely *does* have pass
by reference semantics, even if by the time it reaches the CLR level it
*may* be defined as a "pass pointer by value" operation. (I haven't
checked in enough detail.)

The "by ref"-ness is certainly part of the actual parameter signature
though, in one sense or other. (In the C# sense, it just "is" - in the
IL sense it's just a Foo& parameter rather than a Foo parameter.) Sorry
to bring in the lower levels if you believe they're extraneous, btw.

I certainly can't see any of the normal "Java doesn't have pass by
reference semantics" reasons applying in this case.

 

[Chris Smith]

Hi guys. Good to see you again

You too. We miss you over in cljp. 'Course, we don't give out titles
like "MVP" in exchange for newsgroup answers there.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[sunder]

in reference to below:

StringBuffer g = new StringBuffer( "Hello" );

The variable g does not contain the string "Hello", it contains a
reference (or pointer) to an object instance that contains the
string
"hello".

if that is true then
import java.io.*;
import java.util.*;
public class Test //implements ITest
{
public static void main(String arg[])
{
String str = "Sunder Chitturi";
StringBuffer buffer = new StringBuffer(str);

str = "Utt chitturi";

System.out.println("value now:"+str);
System.out.println("value now:"+buffer.toString());
}
}

the result should be
value now:Utt chitturi
value now:utt Chitturi

No, it shouldn't be for many different reasons. The str = "Utt chitturi";
line does not change the String object that str references it merely points
the str variable to point to another String object. On top of this String
objects are designed to be immutable so that you cannot change String
objects.

its not , I dont think new StringBuffer(String ...) will have a
pointer to string , I think the contents of the string are copied.

It's actually a little more complicated than that, but from a logical
viewpoint that is what happens. In reality it has some optimizations to
delay making a copy until it is needed.

O ya thats what is called late copy or some thing like that !

 

[Roedy Green]

O ya thats what is called late copy or some thing like that !

The usual term is lazy or procrastinated. It anything but lazy from
the programmer's point of view!