ChatGPT解决这个技术问题 Extra ChatGPT

What is a concise way to create a 2D slice in Go?

I am learning Go by going through A Tour of Go. One of the exercises there asks me to create a 2D slice of dy rows and dx columns containing uint8. My current approach, which works, is this:

a:= make([][]uint8, dy)       // initialize a slice of dy slices
for i:=0;i<dy;i++ {
    a[i] = make([]uint8, dx)  // initialize a slice of dx unit8 in each of dy slices
}

I think that iterating through each slice to initialize it is too verbose. And if the slice had more dimensions, the code would become unwieldy. Is there a concise way to initialize 2D (or n-dimensional) slices in Go?


C
Community

There isn't a more concise way, what you did is the "right" way; because slices are always one-dimensional but may be composed to construct higher-dimensional objects. See this question for more details: Go: How is two dimensional array's memory representation.

One thing you can simplify on it is to use the for range construct:

a := make([][]uint8, dy)
for i := range a {
    a[i] = make([]uint8, dx)
}

Also note that if you initialize your slice with a composite literal, you get this for "free", for example:

a := [][]uint8{
    {0, 1, 2, 3},
    {4, 5, 6, 7},
}
fmt.Println(a) // Output is [[0 1 2 3] [4 5 6 7]]

Yes, this has its limits as seemingly you have to enumerate all the elements; but there are some tricks, namely you don't have to enumerate all values, only the ones that are not the zero values of the element type of the slice. For more details about this, see Keyed items in golang array initialization.

For example if you want a slice where the first 10 elements are zeros, and then follows 1 and 2, it can be created like this:

b := []uint{10: 1, 2}
fmt.Println(b) // Prints [0 0 0 0 0 0 0 0 0 0 1 2]

Also note that if you'd use arrays instead of slices, it can be created very easily:

c := [5][5]uint8{}
fmt.Println(c)

Output is:

[[0 0 0 0 0] [0 0 0 0 0] [0 0 0 0 0] [0 0 0 0 0] [0 0 0 0 0]]

In case of arrays you don't have to iterate over the "outer" array and initialize "inner" arrays, as arrays are not descriptors but values. See blog post Arrays, slices (and strings): The mechanics of 'append' for more details.

Try the examples on the Go Playground.


Since using an array simplifies the code, I'd like to do that. How does one specify that in a struct? I get cannot use [5][2]string literal (type [5][2]string) as type [][]string in field value when I try to assign the array to what I guess I'm telling Go is a slice.
Figured it out myself, and edited the answer to add the information.
@EricLindsey While your edit is good, I'm still going to reject it because I don't want to encourage the use of arrays just because initialization is easier. In Go, arrays are secondary, slices are the way to go. For details, see What is the fastest way to append one array to another in Go? Arrays have their places too, for details, see Why have arrays in Go?
fair enough, but I believe the information still has merit. What I was trying to explain with my edit was that if you need the flexibility of differing dimensions between objects then slices are the way to go. On the other hand, if your information is rigidly structured and will always be the same, then arrays are not only easier to initialize, they are also more efficient. How could I improve the edit?
@EricLindsey I see you made another edit which was already rejected by others. In your edit you were saying to use arrays to have faster element access. Note that Go optimizes many things, and this may not be the case, slices may be just as fast. For details, see Array vs Slice: accessing speed.
M
Marcos Canales Mayo

There are two ways to use slices to create a matrix. Let's take a look at the differences between them.

First method:

matrix := make([][]int, n)
for i := 0; i < n; i++ {
    matrix[i] = make([]int, m)
}

Second method:

matrix := make([][]int, n)
rows := make([]int, n*m)
for i := 0; i < n; i++ {
    matrix[i] = rows[i*m : (i+1)*m]
}

In regards to the first method, making successive make calls doesn't ensure that you will end up with a contiguous matrix, so you may have the matrix divided in memory. Let's think of an example with two Go routines that could cause this:

The routine #0 runs make([][]int, n) to get allocated memory for matrix, getting a piece of memory from 0x000 to 0x07F. Then, it starts the loop and does the first row make([]int, m), getting from 0x080 to 0x0FF. In the second iteration it gets preempted by the scheduler. The scheduler gives the processor to routine #1 and it starts running. This one also uses make (for its own purposes) and gets from 0x100 to 0x17F (right next to the first row of routine #0). After a while, it gets preempted and routine #0 starts running again. It does the make([]int, m) corresponding to the second loop iteration and gets from 0x180 to 0x1FF for the second row. At this point, we already got two divided rows.

With the second method, the routine does make([]int, n*m) to get all the matrix allocated in a single slice, ensuring contiguity. After that, a loop is needed to update the matrix pointers to the subslices corresponding to each row.

You can play with the code shown above in the Go Playground to see the difference in the memory assigned by using both methods. Note that I used runtime.Gosched() only with the purpose of yielding the processor and forcing the scheduler to switch to another routine.

Which one to use? Imagine the worst case with the first method, i.e. each row is not next in memory to another row. Then, if your program iterates through the matrix elements (to read or write them), there will probably be more cache misses (hence higher latency) compared to the second method because of worse data locality. On the other hand, with the second method it may not be possible to get a single piece of memory allocated for the matrix, because of memory fragmentation (chunks spread all over the memory), even though theoretically there may be enough free memory for it.

Therefore, unless there's a lot of memory fragmentation and the matrix to be allocated is huge enough, you would always want to use the second method to get advantage of data locality.


golang.org/doc/effective_go.html#slices shows a clever way to do the contiguous memory technique leveraging slice-native syntax (eg no need to explicitly calculate slice boundaries with expressions like (i+1)*m)
To avoid the risk of overlapping when using append the rows should have a locked size: matrix[i] = rows[i*m : (i+1)*m : (i+1)*m]
d
dolmen

With Go 1.18 you get generics.

Here is a function that uses generics to allow to create a 2D slice for any cell type.

func Make2D[T any](n, m int) [][]T {
    matrix := make([][]T, n)
    rows := make([]T, n*m)
    for i, startRow := 0, 0; i < n; i, startRow = i+1, startRow+m {
        endRow := startRow + m
        matrix[i] = rows[startRow:endRow:endRow]
    }
    return matrix
}

With that function in your toolbox, your code becomes:

a := Make2D[uint8](dy, dx)

You can play with the code on the Go Playground.


matrix := make([][]T, n) for i := 0; i < n; i++ { matrix[i] = make([]T, m) }
@echo You are making (n+1) memory allocations while I'm doing just 2.
L
Lucas Eduardo Coelho

Here a consive way to do it:

value := [][]string{}{[]string{}{"A1","A2"}, []string{}{"B1", "B2"}}

PS.: you can change "string" to the type of element you're using in your slice.


The question was about a way to create a 2D slice of dynamic dimensions, which are only known at runtime, not compile time. Therefore this answer doesn't solve the problem. You can take a look at the Go exercise the question is referring to: go.dev/tour/moretypes/18