Move Semantics in Golang

问题:

This from Bjarne Stroustrup's The C++ Programming Language, Fourth Edition 3.3.2.

We didn’t really want a copy; we just wanted to get the result out of a function: we wanted to move a Vector rather than to copy it. Fortunately, we can state that intent:

class Vector {
     // ...

     Vector(const Vector& a);          // copy constructor
     Vector& operator=(const Vector& a);     // copy assignment

     Vector(Vector&& a);               // move constructor
     Vector& operator=(Vector&& a);          // move assignment
};

Given that definition, the compiler will choose the move constructor to implement the transfer of the return value out of the function. This means that r=x+y+z will involve no copying of Vectors. Instead, Vectors are just moved.As is typical, Vector’s move constructor is trivial to define...

I know Golang supports traditional passing by value and passing by reference using Go style pointers.

Does Go support "move semantics" the way C++11 does, as described by Stroustrup above, to avoid the useless copying back and forth? If so, is this automatic, or does it require us to do something in our code to make it happen.

---

Note: A few answers have been posted - I have to digest them a bit, so I haven't accepted one yet - thanks.

回答1:

The breakdown is like here:

1. Everything in Go is passed by value.
2. But there are three built-in "reference types" which are passed by value as well but internally they hold references to separately maintained data structure: maps, slices, channels.

Your own answer, @Vector, is incorrect is that nothing in Go is passed by reference. Rather, there are types with reference semantics. Values of them are still passed by value (sic!).

Your confusion suppsedly stems from the fact your mind is supposedly currently burdened by C++, Java etc while these things in Go are done mostly "as in C".

Take arrays and slices for instance. An array is passed by value in Go, but a slice is a packed struct containing a pointer (to an underlying array) and two platform-sized integers (the length and the capacity of the slice), and it's the value of this structure which is copied — a pointer and two integers — when it's assigned or returned etc. Should you copy a "bare" array, it would be copied literally — with all its elements.

The same applies to channels and maps. You can think of types defining channels and maps as declared something like this:

type Map struct {
   impl *mapImplementation
}

type Slice struct {
   impl *sliceImplementation
}

(By the way, if you know C++, you should be aware that some C++ code uses this trick to lower exposure of the details into header files.)

So when you later have

m := make(map[int]string)

you could think of it as m having the type Map and so when you later do

x := m

the value of m gets copied, but it contains just a single pointer, and so both x and m now reference the same underlying data structure. Was m copied by reference ("move semantics")? Surely not! Do values of type map and slice and channel have reference semantincs? Yes!

Note that these three types of this kind are not at all special: implementing your custom type by embedding in it a pointer to some complicated data structure is a rather common pattern.

In other words, Go allows the programmer to decide what semantics they want for their types. And Go happens to have three built-in types which have reference semantics already (while all the other built-in types have value semantics). Picking one semantics over the other does not affect the rule of copying everything by value in any way. For instance, it's fine to have pointers to values of any kind of type in Go, and assign them (so long they have compatible types) — these pointers will be copied by value.

Another angle to look at this is that many Go packages (standard and 3rd-party) prefer to work with pointers to (complex) values. One example is os.Open() (which opens a file on a filesystem) returning a value of the type *os.File. That is, it returns a pointer and expects the calling code to pass this pointer around. Surely, the Go authors might have declared os.File to be a struct containing a single pointer, essentially making this value have reference semantics but they did not do that. I think the reason for this is that there's no special syntax to work with the values of this type so there's no reason to make them work as maps, channels and slices. KISS, in other words.

---

Recommended reading:

• "Go Data Structures"
• "Go Slices: Usage and Internals"
• Arrays, slices (and strings): The mechanics of 'append'"
• A thead on golang-nuts — pay close attention to the reply by Rob Pike.

回答2:

The Go Programming Language Specification

Calls

In a function call, the function value and arguments are evaluated in the usual order. After they are evaluated, the parameters of the call are passed by value to the function and the called function begins execution. The return parameters of the function are passed by value back to the calling function when the function returns.

In Go, everything is passed by value.

Rob Pike

In Go, everything is passed by value. Everything.

There are some types (pointers, channels, maps, slices) that have reference-like properties, but in those cases the relevant data structure (pointer, channel pointer, map header, slice header) holds a pointer to an underlying, shared object (pointed-to thing, channel descriptor, hash table, array); the data structure itself is passed by value. Always.

Always.

-rob

回答3:

Stroustrup is talking about C++, which allows you to pass containers, etc by value - so the excessive copying becomes an issue.

In Go, (like in Delphi, Java, etc) when you pass a container type, etc they are always references, so it's a non-issue. Regardless, you don't have to deal with it or worry about in GoLang - the compiler just does what it needs to do, and from what I've seen thus far, it's doing it right.

Tnx to @KerrekSB for putting me on the right track.

@KerrekSB - I hope this is the right answer. If it's wrong, you bear no responsibility.:)