[Noob]Function parameters are not pass-by-reference, but what would pass-by-reference look like?

xuanbao · · 675 次点击

这是一个分享于的资源，其中的信息可能已经有所发展或是发生改变。

From the official FAQ: <blockquote> As in all languages in the C family, everything in Go is passed by value. That is, a function always gets a copy of the thing being passed, as if there were an assignment statement assigning the value to the parameter. For instance, passing an int value to a function makes a copy of the int, and passing a pointer value makes a copy of the pointer, but not the data it points to. (See a later section for a discussion of how this affects method receivers.) </blockquote> I thought passing a pointer is passing by reference but it's not. So would pass by reference work? I believe it would be passing the pointer and using that same pointer instead of making a copy. If this is true then would the result of passing a pointer value to a function vs passing a reference to a function be the same? I know Go can't do this. This is more of a general conceptual question. <hr/>**评论：** jerf: <pre>From a modern programming language perspective, it can be difficult to understand what "pass-by-reference" or "pass-by-name" truly means, because every modern language is pass-by-value. That is, there is some sort of distinct "function call", which receives copies of arguments from the caller, proceeds to do its business on its copies, and then returns, destroying its copies in the process. It's easy to get confused by the fact that one of the things that can be passed are references/pointers, so if a function gets passed an *int and uses it to modify something, it may look like there was something "passed by reference". But in fact under the hood, while the function is running, there is two places in memory that have a pointer to the int in question, and no matter what the called function does, it can't change the original pointer. (For that, you could pass a pointer to a pointer, but then the called function can't change that. And so on.) There's a few languages that still simulate this at the language level, where there's a hidden pointer not exposed to you, the programmer, that is passed in, but there's still a copy made of the pointer. Then it looks as if you can have: <pre><code>func Caller() { i := 1 Incr(i) fmt.Println(i) } func Incr(i int) { i += 1 } </code></pre> and have Caller end up printing 2, but there's still a pointer copy. The real "pass-by-name" or "pass-by-reference" languages, though, had very different mechanisms for calling a function that didn't involve making copies of anything. Forth, for instance, had a stack that all functions pulled from, so if you had a stack with <code>[1, 2, 3, 4]</code> on it, and called the <code>+</code> function/operator/word, the result is a stack with <code>[1, 2, 7]</code> in it. No copy of the 3 or 4 was made; the + operator directly operates on the values in the stack, and directly wrote the value back on to the stack, popping the bottom one off (that is, after the 7 is probably still a 4 in memory, to be overwritten the next time the stack grows again). Back in the days of constrained resources, this could be a major advantage for Forth vs. trying to port a language that does copying on every function call when every byte is precious. That's the real alternative to the modern world of "pass-by-value`, but it's almost impossible to point at a modern language currently in use that works that way. Other languages existed that had things that looked like a conventional function call, but hooked up the called function to operate directly on the original input unconditionally, again with no copy made. One of the ways in which your CPU is secretly not really a "general purpose computer" but actually the distant descendant of "a C execution unit" is the way CPUs have developed various fast ways to quickly copy a small amount of parameters into a function without actually hitting RAM, by fiddling with registers and how they are represented, to minimize the penalties associated with the amount of copying this entails. In an alternate universe where Forth won out as the base systems language, the C-like languages would be mocked by the heavy-duty systems programmers as being slow because of all of its copying it has to do, and its inefficient use of the more powerful and flexible stack that processors would be equipped with to run Forth more quickly. Instead we live in a world where Forth has to do some workarounds to make its stack ideas work efficiently and it doesn't necessarily get to take advantage of all the speed hacks to make C work fast.</pre>KeyYam: <pre>whoah, thanks. I had to read this a few times but it makes more sense to me now. Quick question: when you say 'The real "pass-by-name" or "pass-by-value" languages, though..' did you actually mean to say 'The real "pass-by-name" or "pass-by-reference"? </pre>jerf: <pre>Yes, thank you. Fixed.</pre>a_t-2: <pre>a pointer is a value, it's an address. Case point : you can change the value of a pointer. you cannot change what references a reference type. Go actually has kinda reference types : slices. <a href="https://play.golang.org/p/RD6dlboEIpx" rel="nofollow">https://play.golang.org/p/RD6dlboEIpx</a> C++ has reference types so this FAQ is false. <a href="https://en.wikipedia.org/wiki/Reference_(C%2B%2B)" rel="nofollow">https://en.wikipedia.org/wiki/Reference_(C%2B%2B)</a></pre>tv64738: <pre><blockquote> Go actually has kinda reference types : slices. </blockquote> Slices are not refences, they just point to an array that you can mutate. <a href="https://play.golang.org/p/HNuZbxb0rYx" rel="nofollow">https://play.golang.org/p/HNuZbxb0rYx</a> <a href="https://blog.golang.org/slices" rel="nofollow">https://blog.golang.org/slices</a> If you want to argue that Go sort of has reference types, make your argument with map. A map is a pointer, but very early on they decided typing <code>*map[A]B</code> everywhere was awkward, and the language forbid derefencing it anyway, so they just made the asterisk not needed.</pre>a_t-2: <pre><blockquote> Slices are not refences, they just point to an array that you can mutate. </blockquote> Some other languages chose copy on pass when it comes to arrays. Anyway the choice go made is highy debatable.</pre>tv64738: <pre>The choice Go made for arrays is pass-by-value.</pre>kostix: <pre>While slices are not references, they have reference semantics, since assigning a value of a slice type to another variable creates another place referencing the same backing storage array.</pre>tv64738: <pre>Calling slices reference types is confusing because each slice variable has its own copy of len and cap even if they point to the same underlying array. <a href="https://blog.golang.org/slices" rel="nofollow">https://blog.golang.org/slices</a></pre>nagai: <pre>Pass by value creates a local copy of the argument, whereas pass by reference creates an alias of the actual argument. Pointers are no different, they are just variables whose value is the address of some other value. I.e., in go passing down a pointer is essentially just passing down a copy of that address.</pre>govision: <pre>Sorry but I just love these blogs! <a href="https://blog.golang.org/slices" rel="nofollow">https://blog.golang.org/slices</a> <a href="https://blog.golang.org/go-slices-usage-and-internals" rel="nofollow">https://blog.golang.org/go-slices-usage-and-internals</a> They make me want to drop everything and study code. And the one that really explains it! <a href="https://research.swtch.com/godata" rel="nofollow">https://research.swtch.com/godata</a> And of course bill's easier explanation. <a href="https://www.ardanlabs.com/blog/2013/08/understanding-slices-in-go-programming.html" rel="nofollow">https://www.ardanlabs.com/blog/2013/08/understanding-slices-in-go-programming.html</a> And just cause <a href="https://nanxiao.gitbooks.io/golang-101-hacks/content/posts/the-internals-of-slice.html" rel="nofollow">https://nanxiao.gitbooks.io/golang-101-hacks/content/posts/the-internals-of-slice.html</a></pre>