WeChat search
The brain is in the fried fishPay attention to this fried fish with fried liver. In this paper,
GitHub
github.com/eddycjy/blogIs included, with my series of articles, materials, and open source GO books.

Hello, everyone. I’m Fried Fish.

Today is the weekend, although only one day. I want to share with you a quick update on Go1.17. Grow a sucker tip a day!

In the Go language, a slice contains a reference to its supporting array, whether that array exists somewhere as a separate variable or just an anonymous array allocated to support sharding.

The basic structure of the section is as follows:

// runtime/slice.go type slice struct {array unsafe.Pointer // Unsafe.unsafe}

The current array support for slices can lead to interesting memory leaks or surprising changes to your slices.

It’s also important to note that prior to Go 1.16, there was no safe way to convert from slice type to array type.

We can only do this by calling the standard library reflect or unsafe, and by writing unsafe code:

(*[10]byte)(unsafe.Pointer(&b[0]))

Obviously, it’s not elegant. Even the government doesn’t recommend the use of unsafe food, and it can lead to fatal errors if handled incorrectly.

Back in 2009, shortly after the release of Go (and long before the release of Go 1.0), some people raised questions about how to solve this problem:

Finally, in the upcoming Go 1.17, this will be possible because of a series of changes starting with Commission-ID # 1C268431F4 that update the specification:

The new specification describes this in a straightforward way:

Converting a slice to an array pointer yields a pointer to the underlying array of the slice. If the length of the slice is less than the length of the array, a run-time panic occurs.

  • If the length of the slice is longer than the length of the array, it does no harm and works fine.
  • If the length of the slice is longer, it means that your array will not be able to access all the supported arrays of the original slice.

In addition, the specification provides some new examples that we can use in Go1.17:

s := make([]byte, 2, 4) s0 := (*[0]byte)(s) // s0 ! = nil s2 := (*[2]byte)(s) // &s2[0] == &s[0] s4 := (*[4]byte)(s) // panics: len([4]byte) > len(s) var t []string t0 := (*[0]string)(t) // t0 == nil t1 := (*[1]string)(t) // panics: len([1]string) > len(s)
  • Conversion of the s2 variable: It converts the array underlying the slice out. This conversion does not (and cannot) allocate a new array, thus ensuring its efficiency.
  • Conversion of variables s0 and t0: Converts a non-empty fragment to a zero-length array. Even though you can’t do anything with an array of length zero, you still have to give it a valid pointer, which is nil.

Note that there is currently no way to check if he is going to panic for reasons such as crossing the line, as type assertions do. If you think you might have a short clip that could cause a panic event, then you need to use if to prejudge that.

The library Reflect will also be updated to support the conversion from slices to array Pointers. If you are working on this conversion with Reflect, I recommend you read the notes in this submission.

Do you have any other thoughts or concerns about the type conversion in the Go language, or have you stumbled on them?

Please leave a comment in the comments section.

If you have any questions, please feel free to give feedback and exchange in the comment section. The best relationship is mutual achievement. Your thumb up is the biggest motivation for Fried Fish’s creation.

The article is updated continuously, you can search “brain into fried fish” to read, reply [
000I have prepared the first line of big factory interview algorithm solutions and information; In this paper,
GitHub
github.com/eddycjy/blogHas been included, welcome STAR to urge more.