7 ms·

But then you need to explain to a newcomer that you can have `int ptr;` (pointers to pointers)... It's pretty odd for someone coming from say, Python, Java, or

But then you need to explain to a newcomer that you can have `int ptr;` (pointers to pointers)... It's pretty odd for someone coming from say, Python, Java, or JavaScript. (which, many go through years before realizing that pass by reference happens in their language too)

CivBase 6y ago
Is that really any more complicated than arrays of arrays or structs within structs? Pointers to pointers definitely makes things harder to keep track of, but I don't think they're conceptually difficult.
MaxBarraclough 6y ago
> you need to explain to a newcomer that you can have `int ptr;` (pointers to pointers)... I think HN swallowed the asterisks there. I presume you meant: int **ptr; > It's pretty odd for someone coming from say, Python, Java, or JavaScript. (which, many go through years before realizing that pass by reference happens in their language too) That doesn't sound right. Java always passes by value. https://stackoverflow.com/a/40499/ https://stackoverflow.com/a/40499/
- jagged-chisel 6y ago
  > For objects, the pass by value is the value of the reference to the object. That's exactly what "pass by reference" means. According the SO definition, C is always pass by value: the value of the 'primitive' (int, long, char) or the value of the pointer (an address.) It pretty much applies to any language: ultimately you're passing a value from the caller to the callee. Whether that value is 'raw' (say, an int) or a pointer or reference is all in how you (or your compiler, or your runtime) interpret that value you received.
  - MaxBarraclough 6y ago
    > That's exactly what "pass by reference" means No, that's wrong. Pass-by-value with references as values, is not the same as pass-by-reference. Plenty of people make the mistake of equating the two. They can get away with the misconception as long as they don't encounter a language like C# that features both reference types and optional pass-by-reference. > According the SO definition, C is always pass by value That's correct. C is always pass-by-value. You can get a similar effect to pass-by-reference, by passing a pointer. > It pretty much applies to any language: ultimately you're passing a value from the caller to the callee. That's incorrect. If the language has pass-by-reference semantics, then it does not copy the value, it passes the callee a reference to the variable. It's not true of pass-by-name, either, but don't know much about that strategy. A good article on this topic is the documentation on C#'s ref keyword, which enables pass-by-reference. The article does a good job explaining the related concepts. [0] The acid test for whether pass-by-reference is happening, rather than pass-by-value, is whether the asserts can fail in code along the lines of this Java code: int myInt = 42; doStuff(myInt); assert(42 == myInt); // Ok String myString = null; doMoreStuff(myString); assert(null == myString); // Ok In Java, the asserts will never fail. The two methods called do not have access to either the myInt local or the myString local, they only have access to copies of the values held in the two locals. This is the reason Java would permit us to use the final modifier when declaring the two locals, without needing to know anything about either of the called methods. On the other hand, C# permits pass-by-reference. Here we'll suppose that both doStuff and doMoreStuff declared their parameters using the ref keyword: int myInt = 42; doStuff(ref myInt); // If callee uses 'ref' keyword, caller must use it too assert(42 == myInt); // May fail string myString = null; doMoreStuff(ref myString); assert(null == myString); // May fail In this case, either assert may fail, depending on the behaviour of doStuff and doMoreStuff. The callees are given references to our locals, and so they may mutate our locals (as well as reading their values of course). Related to this, this is illegal in C#: doStuff(ref 42); // Compile error. 42 is not a variable! [0] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
    - OskarS 6y ago
      Yes, exactly, all of this. I remember learning Java when I was beginning programming and told that it was "pass by reference except for primitive types which are copied", when that's a total lie! It's not pass by reference at all. I think they said this because C++ copies objects (or nowadays, moves them) when you pass them as arguments (unless you pass by ref), and they wanted to make the distinction with C++ (i.e. "Java doesn't copy objects when you pass them to functions"). But it's done a terrible disservice to the entire industry confusing programmers for years by using the term "pass-by-reference", which has an entirely different meaning. What people mean when they say "Java is pass-by-reference" is that "if you pass a mutable object to a function, the function can mutate it". But that's not the same thing at all.
      - MaxBarraclough 6y ago
        I encountered similar confusion in faculty members as an undergraduate. To resubmit what I wrote in a comment below: It's confusing that we use 'refer to' in two different senses. In Java, a reference-type variable 'refers to' an instance, but overwriting the variable does not impact the referred-to entity. In pass-by-reference, a parameter 'refers to' a variable, and overwriting does impact the referred-to entity. Perhaps we should instead say that in Java, a reference-type variable 'points to' an instance.
    - jagged-chisel 6y ago
      > ...it passes the callee a reference to the variable. And that reference itself is a value-- it's a thing passed to the function and copied from somewhere in memory to a register. It's the interpretation of this value that makes it a reference to some other tangible item. Further, it's the implementation details behind the syntactic sugar, compiler optimizations, and runtime support that allow the developer to reason abstractly with references. Your Java example with String overlooks the fact that String is immutable: the object itself can't be modified. Use any other object type, allow doMotreStuff() to operate on the argument's properties, and you get the same effect as if passing by reference. My point is that the SO explanation isn't a good one precisely because you get this pass-by-reference behavior in Java. Yes, indeed, technically there's this value that gets passed to a function, and it's the value of the reference. And, yes, everything that "passes by reference" has to pass something and that something is the "value of the reference" so everything is technically, at the bottom of the abstract stack, "pass by value." But that's not helpful when attempting to help the newb understand why his object mutated in a method when "pass by value" is what he expected.

CivBase 6y ago

Is that really any more complicated than arrays of arrays or structs within structs? Pointers to pointers definitely makes things harder to keep track of, but I don't think they're conceptually difficult.

MaxBarraclough 6y ago

> you need to explain to a newcomer that you can have `int ptr;` (pointers to pointers)... I think HN swallowed the asterisks there. I presume you meant: int **ptr; > It's pretty odd for someone coming from say, Python, Java, or JavaScript. (which, many go through years before realizing that pass by reference happens in their language too) That doesn't sound right. Java always passes by value. https://stackoverflow.com/a/40499/ https://stackoverflow.com/a/40499/

jagged-chisel 6y ago
> For objects, the pass by value is the value of the reference to the object. That's exactly what "pass by reference" means. According the SO definition, C is always pass by value: the value of the 'primitive' (int, long, char) or the value of the pointer (an address.) It pretty much applies to any language: ultimately you're passing a value from the caller to the callee. Whether that value is 'raw' (say, an int) or a pointer or reference is all in how you (or your compiler, or your runtime) interpret that value you received.
- MaxBarraclough 6y ago
  > That's exactly what "pass by reference" means No, that's wrong. Pass-by-value with references as values, is not the same as pass-by-reference. Plenty of people make the mistake of equating the two. They can get away with the misconception as long as they don't encounter a language like C# that features both reference types and optional pass-by-reference. > According the SO definition, C is always pass by value That's correct. C is always pass-by-value. You can get a similar effect to pass-by-reference, by passing a pointer. > It pretty much applies to any language: ultimately you're passing a value from the caller to the callee. That's incorrect. If the language has pass-by-reference semantics, then it does not copy the value, it passes the callee a reference to the variable. It's not true of pass-by-name, either, but don't know much about that strategy. A good article on this topic is the documentation on C#'s ref keyword, which enables pass-by-reference. The article does a good job explaining the related concepts. [0] The acid test for whether pass-by-reference is happening, rather than pass-by-value, is whether the asserts can fail in code along the lines of this Java code: int myInt = 42; doStuff(myInt); assert(42 == myInt); // Ok String myString = null; doMoreStuff(myString); assert(null == myString); // Ok In Java, the asserts will never fail. The two methods called do not have access to either the myInt local or the myString local, they only have access to copies of the values held in the two locals. This is the reason Java would permit us to use the final modifier when declaring the two locals, without needing to know anything about either of the called methods. On the other hand, C# permits pass-by-reference. Here we'll suppose that both doStuff and doMoreStuff declared their parameters using the ref keyword: int myInt = 42; doStuff(ref myInt); // If callee uses 'ref' keyword, caller must use it too assert(42 == myInt); // May fail string myString = null; doMoreStuff(ref myString); assert(null == myString); // May fail In this case, either assert may fail, depending on the behaviour of doStuff and doMoreStuff. The callees are given references to our locals, and so they may mutate our locals (as well as reading their values of course). Related to this, this is illegal in C#: doStuff(ref 42); // Compile error. 42 is not a variable! [0] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
  - OskarS 6y ago
    Yes, exactly, all of this. I remember learning Java when I was beginning programming and told that it was "pass by reference except for primitive types which are copied", when that's a total lie! It's not pass by reference at all. I think they said this because C++ copies objects (or nowadays, moves them) when you pass them as arguments (unless you pass by ref), and they wanted to make the distinction with C++ (i.e. "Java doesn't copy objects when you pass them to functions"). But it's done a terrible disservice to the entire industry confusing programmers for years by using the term "pass-by-reference", which has an entirely different meaning. What people mean when they say "Java is pass-by-reference" is that "if you pass a mutable object to a function, the function can mutate it". But that's not the same thing at all.
    - MaxBarraclough 6y ago
      I encountered similar confusion in faculty members as an undergraduate. To resubmit what I wrote in a comment below: It's confusing that we use 'refer to' in two different senses. In Java, a reference-type variable 'refers to' an instance, but overwriting the variable does not impact the referred-to entity. In pass-by-reference, a parameter 'refers to' a variable, and overwriting does impact the referred-to entity. Perhaps we should instead say that in Java, a reference-type variable 'points to' an instance.
  - jagged-chisel 6y ago
    > ...it passes the callee a reference to the variable. And that reference itself is a value-- it's a thing passed to the function and copied from somewhere in memory to a register. It's the interpretation of this value that makes it a reference to some other tangible item. Further, it's the implementation details behind the syntactic sugar, compiler optimizations, and runtime support that allow the developer to reason abstractly with references. Your Java example with String overlooks the fact that String is immutable: the object itself can't be modified. Use any other object type, allow doMotreStuff() to operate on the argument's properties, and you get the same effect as if passing by reference. My point is that the SO explanation isn't a good one precisely because you get this pass-by-reference behavior in Java. Yes, indeed, technically there's this value that gets passed to a function, and it's the value of the reference. And, yes, everything that "passes by reference" has to pass something and that something is the "value of the reference" so everything is technically, at the bottom of the abstract stack, "pass by value." But that's not helpful when attempting to help the newb understand why his object mutated in a method when "pass by value" is what he expected.