ChatGPT解决这个技术问题 Extra ChatGPT

Why can't I duplicate a slice with `copy()`?

I need to make a copy of a slice in Go and reading the docs there is a copy function at my disposal.

The copy built-in function copies elements from a source slice into a destination slice. (As a special case, it also will copy bytes from a string to a slice of bytes.) The source and destination may overlap. Copy returns the number of elements copied, which will be the minimum of len(src) and len(dst).

But when I do:

arr := []int{1, 2, 3}
tmp := []int{}
copy(tmp, arr)
fmt.Println(tmp)
fmt.Println(arr)

My tmp is empty as it was before (I even tried to use arr, tmp):

[]
[1 2 3]

You can check it on go playground. So why can not I copy a slice?

thanks everyone, it is really sad that I have not noticed that slices should be the same length.
Not necessarily the same, but dst should be at least as big as many elements you want to copy (for a full copy of src it means len(dst) >= len(src)).
b := append([]int{}, a...)

i
icza

The builtin copy(dst, src) copies min(len(dst), len(src)) elements.

So if your dst is empty (len(dst) == 0), nothing will be copied.

Try tmp := make([]int, len(arr)) (Go Playground):

arr := []int{1, 2, 3}
tmp := make([]int, len(arr))
copy(tmp, arr)
fmt.Println(tmp)
fmt.Println(arr)

Output (as expected):

[1 2 3]
[1 2 3]

Unfortunately this is not documented in the builtin package, but it is documented in the Go Language Specification: Appending to and copying slices:

The number of elements copied is the minimum of len(src) and len(dst).

Edit:

Finally the documentation of copy() has been updated and it now contains the fact that the minimum length of source and destination will be copied:

Copy returns the number of elements copied, which will be the minimum of len(src) and len(dst).


To summarise, copy doesn't contain logic for growing the destination slice if the destination slice is too small, but there is another built-in function that does: append While in this example it's better just to allocate the right sized slice in the first place, append can be used when you already have a slice and want to grow it by adding elements to the end.
But why do I have to create a bounded size slice when copying an unbounded sized slice?
D
Dave

Another simple way to do this is by using append which will allocate the slice in the process.

arr := []int{1, 2, 3}
tmp := append([]int(nil), arr...)  // Notice the ... splat
fmt.Println(tmp)
fmt.Println(arr)

Output (as expected):

[1 2 3]
[1 2 3]

As pointed out in the comments below, append may allocate excess memory if the slice isn't sized correctly to begin with. A nice solution to this is to preallocate a slice of the right capacity, like so:

tmp := append(make([]int, 0, len(arr)), arr...)

So a shorthand for copying array arr would be append(make([]int, 0, len(arr)), arr...)

https://play.golang.org/p/xwevI1chGrd


the catch here is that in real-world examples, which are much larger, append will allocate excess memory -- unless this array is later filled to capacity by some further processing -- because it is designed for efficient reallocation over repeated calls. play.golang.org/p/5_6618xnXn observe that cap(x) increases to 12, not 10. now look what happens when 1 value is added to 1048576 values play.golang.org/p/nz32JPehhl the capacity jumps by 2048 slots to 1050624, to accommodate only one additional value.
Another option that allows for an in-line solution which simultaneously addresses the issue brought forth by @j.andrewshusta is to initialize the capacity of the input slice like so: tmp := append(make([]int, 0, len(arr)), arr...). Under the hood, the append function checks the capacity of the slice on each call, allocating a new slice if the capacity is about to be exceeded. This solution has the added benefit of circumventing the repeated re-allocations.
Just for FYI, using copy() from my benchmarks is about 15% faster. OTOH copy() is more complicated to use, as this Go Playground illustrates go.dev/play/p/XDGuVU0xfRy — Benchmarks and results here gist.github.com/mikeschinkel/fbeb291b90970581b4428fbc14e4ab19 as you can can't benchmark reliably on a shared server. HOWEVER, I would normally still use the append() method because it is easier to understand and less likely to break than the copy() version unless performance is absolutely critical for a given use-case.
E
Esze

The copy() runs for the least length of dst and src, so you must initialize the dst to the desired length.

A := []int{1, 2, 3}
B := make([]int, 3)
copy(B, A)
C := make([]int, 2)
copy(C, A)
fmt.Println(A, B, C)

Output:

[1 2 3] [1 2 3] [1 2]

You can initialize and copy all elements in one line using append() to a nil slice.

x := append([]T{}, []...)

Example:

A := []int{1, 2, 3}
B := append([]int{}, A...)
C := append([]int{}, A[:2]...)
fmt.Println(A, B, C)    

Output:

[1 2 3] [1 2 3] [1 2]

Comparing with allocation+copy(), for greater than 1,000 elements, use append. Actually bellow 1,000 the difference may be neglected, make it a go for rule of thumb unless you have many slices.

BenchmarkCopy1-4                50000000            27.0 ns/op
BenchmarkCopy10-4               30000000            53.3 ns/op
BenchmarkCopy100-4              10000000           229 ns/op
BenchmarkCopy1000-4              1000000          1942 ns/op
BenchmarkCopy10000-4              100000         18009 ns/op
BenchmarkCopy100000-4              10000        220113 ns/op
BenchmarkCopy1000000-4              1000       2028157 ns/op
BenchmarkCopy10000000-4              100      15323924 ns/op
BenchmarkCopy100000000-4               1    1200488116 ns/op
BenchmarkAppend1-4              50000000            34.2 ns/op
BenchmarkAppend10-4             20000000            60.0 ns/op
BenchmarkAppend100-4             5000000           240 ns/op
BenchmarkAppend1000-4            1000000          1832 ns/op
BenchmarkAppend10000-4            100000         13378 ns/op
BenchmarkAppend100000-4            10000        142397 ns/op
BenchmarkAppend1000000-4            2000       1053891 ns/op
BenchmarkAppend10000000-4            200       9500541 ns/op
BenchmarkAppend100000000-4            20     176361861 ns/op

append should be used in cases where the array will be increased by repeated calls, as it will optimistically allocate excess capacity in anticipation of this. copy should be used once per input array in cases where the result array should be created to exact size, and is not reallocated from again. play.golang.org/p/0kviwKmGzx you didn't share the benchmark code that produced those results so i can't confirm or deny its validity, but it overlooks this more important aspect.
You mean 'slice' not array. They're different things.
i
icza

If your slices were of the same size, it would work:

arr := []int{1, 2, 3}
tmp := []int{0, 0, 0}
i := copy(tmp, arr)
fmt.Println(i)
fmt.Println(tmp)
fmt.Println(arr)

Would give:

3
[1 2 3]
[1 2 3]

From "Go Slices: usage and internals":

The copy function supports copying between slices of different lengths (it will copy only up to the smaller number of elements)

The usual example is:

t := make([]byte, len(s), (cap(s)+1)*2)
copy(t, s)
s = t

D
Debapriya Biswas

The best way to clone as slice is

sClone = append(s[:0:0], s...)

This implementation has two advantage:

make sure that the result sClone is nil if s is nil, and is not nil if s is not nil. No need to import the containing package of type T even if T is declared in another package


thanks for this good answer, it's worth more than an upvote!
p
peterSO

The Go Programming Language Specification Appending to and copying slices The function copy copies slice elements from a source src to a destination dst and returns the number of elements copied. Both arguments must have identical element type T and must be assignable to a slice of type []T. The number of elements copied is the minimum of len(src) and len(dst). As a special case, copy also accepts a destination argument assignable to type []byte with a source argument of a string type. This form copies the bytes from the string into the byte slice. copy(dst, src []T) int copy(dst []byte, src string) int

tmp needs enough room for arr. For example,

package main

import "fmt"

func main() {
    arr := []int{1, 2, 3}
    tmp := make([]int, len(arr))
    copy(tmp, arr)
    fmt.Println(tmp)
    fmt.Println(arr)
}

Output:

[1 2 3]
[1 2 3]

x
xilpex

NOTE: This is an incorrect solution as @benlemasurier proved

Here is a way to copy a slice. I'm a bit late, but there is a simpler, and faster answer than @Dave's. This are the instructions generated from a code like @Dave's. These is the instructions generated by mine. As you can see there are far fewer instructions. What is does is it just does append(slice), which copies the slice. This code:

package main

import "fmt"

func main() {
    var foo = []int{1, 2, 3, 4, 5}
    fmt.Println("foo:", foo)
    var bar = append(foo)
    fmt.Println("bar:", bar)
    bar = append(bar, 6)
    fmt.Println("foo after:", foo)
    fmt.Println("bar after:", bar)
}

Outputs this:

foo: [1 2 3 4 5]
bar: [1 2 3 4 5]
foo after: [1 2 3 4 5]
bar after: [1 2 3 4 5 6]

This is incorrect, as show here: play.golang.org/p/q3CoEoaid6d. The expected output should reflect that of @Dave's answer: play.golang.org/p/mgdJ4voSlpd
@benlemasurier -- Huh... Seems you're right! Thanks for letting me know!
S
Sumer

Sweet, Simple, Performant, No need to be careful of length, No Memory overlap, Different copies

slice2 := append([]int{}, slice1...)

s
shooma

If you don't care about the speed:

import "golang.org/x/exp/slices"

tmp := slices.Clone(arr)

With Go 1.18 and generics, any slices now could be copied with slices.Clone from package "golang.org/x/exp/slices". Playground