Ok, it's good that you've worked your logic through to produce the claim that C passes by reference.
This is good, because we know that it is clearly untrue, which means that your logic has a faulty premise. :)
Let's check to see if x was passed by reference.
If x was passed by reference, then modifying the parameter would modify the argument.
Does the assignment to p affect x?
No.
Therefore p is not a reference to x.
Therefore x was not passed by reference.
So, what is the reference to x?
It is *p.
We can test this with *p = 4; which will change the value of x, since *p is a reference to x.
Which solves the problem nicely.
&x is a pointer to x, not a reference to x.
&x would be a reference to x, but since C has only pass by value foo(&x) will pass the value of the reference to x, which is the value of x, and not a reference to x.
&x is not x.
Therefore foo(&x) does not pass x by reference to foo, and there is no way to pass a reference to x to foo.
(Which is unsurprising, since C does not support pass by reference)
What you can do is to pass the value of a pointer from which an alias (reference) may later be constructed -- but this is not pass by reference, and it is not passing the object pointed at by the pointer.
OK so I see what is happening, you are talking about passing the symbol by reference, when I clearly state the int was passed by reference. But it looks like we need to define some more items from the spec so that we are clear.
Reference operator -> &
Dereference operator -> *
intx;int*p;// declare a reference to integerp=&x;// take the address of x*p=6;// Dereference p and assign 6 to the integer
This creates a difference from the way you described these synthetic descriptions. Going forward keep in mind that I have already established that the C spec has specified that pointers are references.
p is a reference
*p removes reference to allow modifying the referenced data
&x creates a reference to x
foo(&x) a reference to x is passed into foo by value
Since you brought up passing symbols by reference, let's take a look at that.
6.5.3.2 Address and indirection operators
The unary & operator yields the address of its operand.
The unary * operator denotes indirection. [...] if it points to an object, the result is an lvalue designating the object.
&x just produces a pointer to x -- that's all.
*x just produces the lvalue (the object, not the value of the object) that x points at.
An lvalue in C corresponds with what is called a reference in other languages -- it's what allows you to write things like *x = y;
This is in contrast with 'reference values' in Java, and so on, which correspond with restricted pointers, rather than references (and why they're qualified as 'reference values').
And you can see this in how languages which do have first class references, like C++, work.
voidfoo(int&a,int*b){a=1;// Modifying the parameter modifies the argument.b=0;// Modifying the parameter does not modify the argument.}{intx=0;inty=0;foo(x,&y);// x = 1 (x was passed by reference and modified)// y = 0 (y was not passed; a pointer to y was passed by value)}
A pointer doesn't correspond with a reference -- but it allows you to later produce an lvalue which does.
passing the argument, which may be an lvalue.
[...]
An lvalue in C corresponds with what is called a reference in other languages
[...]
the lvalue (the object, not the value of the object)
So let's ignore that I already established that the spec equates pointers as references.
lvalue -> reference
lvalue -> object
x -> is an lvalue
x -> argument
lvalue is not the value.
Good, I'm glad this is at least consistent with your claim. x being an lvalue and it is an argument, we know that the argument is passed by value. We can conclude that
we have passed a reference by value
we have passed the object by value
No, seriously, more and more terms are being thrown in and to define them existing terms we have not come to a consensus on are used. This just makes the entire conversation an battle of adding terms. Luckily I did not see 'references' or 'Dereference' in the spec so those can be thrown out.
No, that is written in the spec meaning they can use "reference" to mean reference value. Reference is just an alias to reference value. Like
"The values of a reference type are references to objects."
It doesn't mean that "reference value" means "a reference" in the sense of other languages, such as C++.
But now you are doing what you told me not to do. That is the specification of a different language not for Java.
My only disagreement is about introducing 'object references' or claiming that there is 'pass by reference' -- these exist in neither language.
"All interactions with objects and array is by reference, much like pointers in C."
I had not made reference to either of those things, yet you did take issue with my statement
If that statement means objects are pass by reference. Then I need to defend that Java has it. If it does not, then why do you take such great efforts to disagree with it?
It's trivial to show that pass by reference doesn't occur in Java, since changes to the parameter are independent of changes to the argument.
Once you understand that, it should be clear that the "reference value" is not the object that it refers to.
Which means that passing a "reference value" is not passing the object is refers to -- it just passes a means by which to interact with the object it refers to.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
This is impressively long. I feel like you have both made important connection, perhaps you should make a post together 😊 certainly a lot to digest here.
the C spec, "A pointer type describes an object whose value provides a reference to an entity of the referenced type"
See C did not need to worry about conflating reference type semantics because they did not have the feature.
We are back to the same problem, you do not accept the language of the spec because you have a different language spec which you prefer to use over the others.
Yes, C is very clear that a pointer isn't a reference.
Its value can provide a reference (via *p).
The problem is that you're taking words from different specifications and conflating them without considering the semantics of the word within that specification.
And this is leading to clearly false conclusions, such as your assertion that pointers are references, and that passing pointers is pass by reference.
I am taking words from the C spec when talking about C. I'm taking words from the Java spec when talking about Java. You are the one taking words from the C++ spec when talking about languages that are not C++.
The Java spec has defined use of the word "reference" to mean "reference value?"
Feel free to disagree with the Java spec. I needed to know if when we read something we can come to the same conclusion about what it says. And that if we discuss things on an agreed upon definition it does not change because a different definition exists for the same term and is better suited for the argument at hand.
You're spending so much effort being right rather than communicate.
You're trying to prove that this scotsman is not a true scotsman. And fail to recognize that he is in fact a scotsman.
Rather than directly addressing the definition of reference. You run me in circles. First by saying I needed to use the words of the spec, then by saying those words aren't the same in this other spec.
I pull in a third-party which you completely ignore, probably because it doesn't match your true scotsman. You try to show me differences, even though I clearly demonstrated an understanding of the different semantics.
You can only accept being right and have no interest in communicating.
Had you accepted the words used in the Java spec I could have answered No to the question about the behavior of C.
C did use the word reference, but it was not trying to define a language construct, instead it was using the word to help explain the semantics of a pointer, this matches the definition provided by Wikipedia.
Java on the other hand is defining a language construct. It has different semantics then C++'s use with the same name.
So we have reference as a concept, reference as a language construct in Java, and reference as a language construct in C++. Thus in order to communicate we have to agree to which of these we mean.
I thought that you would use the one defined in the language spec since that is what requested at the start. When I realized you were not sticking to that requirement, I was able to pull in more language into the mix and see how you would contort your logic to make it seem that all of these uses are consistent (they are not). But I was sadly disappointed when you wouldn't even touch Wikipedia definition.
Since we are talking about pass-by-reference, it is the semantics of pass-by-reference that are significant.
If your definition of 'reference' is 'something that can be used to find something', then there will be nothing that is not a reference.
Have a string? I can use that to reference something .: strings are references!
Have an integer? I can use that to reference something .: integers are references!
Have anything? I can use that to reference something .: anything is a reference.
Which is the path down which you are going by claiming that pointers are references, because they can reference things, and therefore passing a pointer to something is passing that something by reference.
It's meaningless -- which is why I have kept bringing it back to the semantics required by pass-by-reference.
And why I started with your ask, to use the Java spec which does not define them as you have here. My point was that we never established an agreed and consistent definition for reference.
I never once saw you pull out a definition from your sources. Even definition I had to dig for and you would deflect because it wasn't the one you wanted.
And I talked about the Java spec, which defines "references values" (abbreviated sometimes to references).
These are not references in the sense of pass-by-value, as I've demonstrated many times above.
You might claim that they're references in the sense that anything can be used to refer to something else.
But that won't get you references with the semantics required by pass-by-reference, which means that you can't claim that passing one is pass-by-reference.
Let's just imagine that they were called "oranges" -- would you be claiming that passing an "orange" gave you pass-by-reference?
If not, then it's clear that this is simply due to being confused by a name choice.
Under that definition, no passing by oranges does not have the same semantics as pass by reference.
This however changes the subject to the parameters of the functions. I have been talking about the object for which the parameter refers. Could we stick with talking about the concept I'm actually trying to get across rather than introducing a introducing a different one.
Since pass by oranges is not a term used in the Java spec, could you describe the pass by oranges semantics using spec terms?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ok, it's good that you've worked your logic through to produce the claim that C passes by reference.
This is good, because we know that it is clearly untrue, which means that your logic has a faulty premise. :)
Let's check to see if x was passed by reference.
If x was passed by reference, then modifying the parameter would modify the argument.
Does the assignment to p affect x?
No.
Therefore p is not a reference to x.
Therefore x was not passed by reference.
So, what is the reference to x?
It is *p.
We can test this with *p = 4; which will change the value of x, since *p is a reference to x.
Which solves the problem nicely.
Therefore foo(&x) does not pass x by reference to foo, and there is no way to pass a reference to x to foo.
(Which is unsurprising, since C does not support pass by reference)
What you can do is to pass the value of a pointer from which an alias (reference) may later be constructed -- but this is not pass by reference, and it is not passing the object pointed at by the pointer.
OK so I see what is happening, you are talking about passing the symbol by reference, when I clearly state the int was passed by reference. But it looks like we need to define some more items from the spec so that we are clear.
Reference operator -> &
Dereference operator -> *
This creates a difference from the way you described these synthetic descriptions. Going forward keep in mind that I have already established that the C spec has specified that pointers are references.
p
is a reference*p
removes reference to allow modifying the referenced data&x
creates a reference to xfoo(&x)
a reference to x is passed into foo by valueSince you brought up passing symbols by reference, let's take a look at that.
You can't pass symbols in C.
I'm talking about passing the argument, which may be an lvalue.
However, I think your terms are quite off regarding C.
& is not a reference operator.
open-std.org/jtc1/sc22/wg14/www/do...
&x just produces a pointer to x -- that's all.
*x just produces the lvalue (the object, not the value of the object) that x points at.
An lvalue in C corresponds with what is called a reference in other languages -- it's what allows you to write things like *x = y;
This is in contrast with 'reference values' in Java, and so on, which correspond with restricted pointers, rather than references (and why they're qualified as 'reference values').
And you can see this in how languages which do have first class references, like C++, work.
A pointer doesn't correspond with a reference -- but it allows you to later produce an lvalue which does.
How many times do I need to quote the Java spec you referenced.
"The reference values (often just references)"
So let's ignore that I already established that the spec equates pointers as references.
lvalue -> reference
lvalue -> object
x
-> is an lvaluex
-> argumentlvalue is not the value.
Good, I'm glad this is at least consistent with your claim.
x
being an lvalue and it is an argument, we know that the argument is passed by value. We can conclude thatNo, seriously, more and more terms are being thrown in and to define them existing terms we have not come to a consensus on are used. This just makes the entire conversation an battle of adding terms. Luckily I did not see 'references' or 'Dereference' in the spec so those can be thrown out.
So let me try again, do you agree and why:
For Java
Reference values -> commonly just reference
Reference value -> points to an object
Reference values are passed by value
For C:
Pointer -> reference to an entity
The spec does not equate references with pointers, and it's trivial to demonstrate that pointers do not have the semantics of references.
This is a critical requirement for pass-by-reference semantics.
This is also why C does not support pass-by-reference while it does support passing pointers.
What that means is that people often abbreviate "reference value" as "reference".
It doesn't mean that "reference value" means "a reference" in the sense of other languages, such as C++.
Here's a nice article which explains this in detail for Java, with references to the standard.
javadude.com/articles/passbyvalue.htm
No, that is written in the spec meaning they can use "reference" to mean reference value. Reference is just an alias to reference value. Like
"The values of a reference type are references to objects."
But now you are doing what you told me not to do. That is the specification of a different language not for Java.
"All interactions with objects and array is by reference, much like pointers in C."
I had not made reference to either of those things, yet you did take issue with my statement
If that statement means objects are pass by reference. Then I need to defend that Java has it. If it does not, then why do you take such great efforts to disagree with it?
It's trivial to show that pass by reference doesn't occur in Java, since changes to the parameter are independent of changes to the argument.
Once you understand that, it should be clear that the "reference value" is not the object that it refers to.
Which means that passing a "reference value" is not passing the object is refers to -- it just passes a means by which to interact with the object it refers to.
This is what I have been saying. The object is not passed. A reference is passed and that reference, points to an object.
This is impressively long. I feel like you have both made important connection, perhaps you should make a post together 😊 certainly a lot to digest here.
the C spec, "A pointer type describes an object whose value provides a reference to an entity of the referenced type"
See C did not need to worry about conflating reference type semantics because they did not have the feature.
We are back to the same problem, you do not accept the language of the spec because you have a different language spec which you prefer to use over the others.
Yes, C is very clear that a pointer isn't a reference.
Its value can provide a reference (via *p).
The problem is that you're taking words from different specifications and conflating them without considering the semantics of the word within that specification.
And this is leading to clearly false conclusions, such as your assertion that pointers are references, and that passing pointers is pass by reference.
I am taking words from the C spec when talking about C. I'm taking words from the Java spec when talking about Java. You are the one taking words from the C++ spec when talking about languages that are not C++.
Are you still claiming that in C passing the value of a pointer to an int object to a function is passing the int object by reference?
"All interactions with objects and array is by reference, much like pointers in C."
Does this mean Java is pass by reference?
Is this statement wrong for Java?
Why won't you answer my questions for clarifying our disagreement?
Let's write it out properly.
"All interactions with objects and arrays is by reference values, much like pointers in C."
This does not mean that Java is pass-by-reference.
Reference values in Java are values and are passed by value like any other value in Java.
This is easy to test, since modifying a parameter in Java does not affect the corresponding argument.
It means that like pointers, they are not references, but can be operated upon to access an object indirectly.
In C, *p is used to access the object that pointer p points at.
In Java, p.x is used to access member x of the object that p refers to (if p happens to refer to an object, that is).
"The reference values (often just references)"
The Java spec has defined use of the word "reference" to mean "reference value?"
Feel free to disagree with the Java spec. I needed to know if when we read something we can come to the same conclusion about what it says. And that if we discuss things on an agreed upon definition it does not change because a different definition exists for the same term and is better suited for the argument at hand.
The Java spec has defined "reference values" and then said that "reference value" is often abbreviated as "references".
This is what "The reference values (often just references)" means.
Which means that when you read "references" in Java, you need to mentally expand it back out to "reference values".
If you don't do this, you'll end up making errors like claiming that Java supports pass-by-reference.
That sounds more like a no to me. Should have chosen yes.
Since it appears that we can choose our preferred definition with no authority on the matter, I choose Wikipedia.
Yes.
Feel free to change my mind by updating the Wikipedia page. I'm sure it will go through unquestioned with your references.
If you believe that C has pass-by-reference semantics, there's really no point continuing the conversation.
Best of luck.
That isn't what you asked.
This is what I asked
This is what you answered
Passing by reference requires pass-by-reference semantics.
So, it is what I asked.
Do you believe that C have pass-by-reference semantics?
If you pass an address to a function then you have passed the int by reference.
C does not have pass-by-reference semantics and will not pass int by reference.
Java interacts with objects by reference. When you call a method you pass the object by reference.
Java does not have pass-by-reference semantics and will not pass an object reference by reference.
Passing an int * in C does not pass an int.
Right you're passing a reference to int.
No, you're passing the value of an int *.
You're spending so much effort being right rather than communicate.
You're trying to prove that this scotsman is not a true scotsman. And fail to recognize that he is in fact a scotsman.
Rather than directly addressing the definition of reference. You run me in circles. First by saying I needed to use the words of the spec, then by saying those words aren't the same in this other spec.
I pull in a third-party which you completely ignore, probably because it doesn't match your true scotsman. You try to show me differences, even though I clearly demonstrated an understanding of the different semantics.
You can only accept being right and have no interest in communicating.
Had you accepted the words used in the Java spec I could have answered No to the question about the behavior of C.
C did use the word reference, but it was not trying to define a language construct, instead it was using the word to help explain the semantics of a pointer, this matches the definition provided by Wikipedia.
Java on the other hand is defining a language construct. It has different semantics then C++'s use with the same name.
So we have reference as a concept, reference as a language construct in Java, and reference as a language construct in C++. Thus in order to communicate we have to agree to which of these we mean.
I thought that you would use the one defined in the language spec since that is what requested at the start. When I realized you were not sticking to that requirement, I was able to pull in more language into the mix and see how you would contort your logic to make it seem that all of these uses are consistent (they are not). But I was sadly disappointed when you wouldn't even touch Wikipedia definition.
Since we are talking about pass-by-reference, it is the semantics of pass-by-reference that are significant.
If your definition of 'reference' is 'something that can be used to find something', then there will be nothing that is not a reference.
Have a string? I can use that to reference something .: strings are references!
Have an integer? I can use that to reference something .: integers are references!
Have anything? I can use that to reference something .: anything is a reference.
Which is the path down which you are going by claiming that pointers are references, because they can reference things, and therefore passing a pointer to something is passing that something by reference.
It's meaningless -- which is why I have kept bringing it back to the semantics required by pass-by-reference.
And why I started with your ask, to use the Java spec which does not define them as you have here. My point was that we never established an agreed and consistent definition for reference.
I never once saw you pull out a definition from your sources. Even definition I had to dig for and you would deflect because it wasn't the one you wanted.
And I talked about the Java spec, which defines "references values" (abbreviated sometimes to references).
These are not references in the sense of pass-by-value, as I've demonstrated many times above.
You might claim that they're references in the sense that anything can be used to refer to something else.
But that won't get you references with the semantics required by pass-by-reference, which means that you can't claim that passing one is pass-by-reference.
Let's just imagine that they were called "oranges" -- would you be claiming that passing an "orange" gave you pass-by-reference?
If not, then it's clear that this is simply due to being confused by a name choice.
Let's try it.
"reference values (often just oranges)"
"All interactions with objects and array is by oranges, much like pointers in C."
Yep, I'd use it.
"Objects are pass by oranges and if C had them, it too would be pass by oranges."
Ok, and does pass-by-orange have pass-by-reference semantics, or does it have pass-by-value semantics? :)
Have we defined what we are discussing as passed and the definition of reference yet?
I've done so several times.
Here is the simplest requirement, again.
When passing by reference, modifying the parameter modifies the argument.
Under that definition, no passing by oranges does not have the same semantics as pass by reference.
This however changes the subject to the parameters of the functions. I have been talking about the object for which the parameter refers. Could we stick with talking about the concept I'm actually trying to get across rather than introducing a introducing a different one.
Since pass by oranges is not a term used in the Java spec, could you describe the pass by oranges semantics using spec terms?