为什么在Go中有数组？ [英] Why have arrays in Go?

问题描述

我明白Go中数组和片的区别。但是我不明白的是为什么数组完全有帮助。为什么数组类型定义指定长度和元素类型会有帮助？为什么我们使用的每个数组都不是一个分片？ ：//golang.org/ref/spec#Array_typesrel =nofollow noreferrer>数组，而不仅仅是固定长度： 可比 ，它们是值（不是引用或指针类型）。

在某些情况下，数组相对于数组具有无数的优点，所有这些优点都超过了证明数组存在（与切片一起）的理由。我们来看看他们。 （我甚至没有把数组当作片的构建块）。

---

1。可比较意味着你可以在地图中使用数组作为键，但不能使用切片。是的，你现在可以说，为什么不让切片与之相当，所以单凭这一点就不能证明两者的存在。平等在切片上没有很好的定义。 常见问题：为什么地图不允许切片作为关键字？

它们不实现相等性，因为在这些类型上没有很好地定义相等性;有很多考虑因素涉及浅层比较深度比较，指针与值比较，如何处理递归类型等。

2。 数组也可以为您提供更高的编译时安全性，因为可以在编译时检查索引边界（数组长度必须评估为非负数常量可由类型 int 的值表示） ：

  s：= make（[] int，3）
s [3] = 3 //Only运行时错误：运行时错误：索引超出范围
 
a：= [3] int {} 
a [3] = 3 //编译时错误：数组索引3无效3元素数组的限制）
  

3。 传递围绕或分配数组值将隐式地创建整个数组的一个副本，所以它将与原始值分离。如果传递一个片段，它仍然会创建一个副本，但只是片段头部，但片段值（头部）将指向相同的支持数组。这可能是也可能不是你想要的。如果你想从原始中分离切片，你必须明确地复制内容，例如内置 copy（） 函数到一个新的切片。

  a：= [2] int {1，2} 
b：= a 
b [0] = 10 //这只影响b，a将保持{1,2} 
 
 sa：= [] int {1,2，$} 
 sb：= sa 
 sb [0] = 10 //影响sb和​​sa 
  

4 。另外，由于数组长度是数组类型的一部分，因此不同长度的数组是不同类型的。一方面，这可能是一个痛苦的屁股（例如，你写一个函数，它的参数类型为 [4] int ），你不能使用该函数以获取和处理 [5] int 类型的数组），但这也可能是一个优点：这可能用于显式指定长度预期的阵列。例如。你想写一个需要IPv4地址的函数，它可以用 [4] byte 类型建模。现在你有一个编译时间的保证，传递给你的函数的值将有正好4个字节，不多也不少（这将是一个无效的IPv4地址）。

5。与前面的内容相关，数组长度也可用于文档目的。类型 [4]字节恰当地表明IPv4有4个字节。 [3] byte 类型的 rgb 变量告诉每个颜色分量有1个字节。在某些情况下，它甚至被取出并可用，分开记录;例如在 crypto / md5 包： md5.Sum（） 返回一个类型为 [Size] byte 的值，其中 md5.Size 是一个常量< 16 ：MD5校验和的长度。

6。 strong>规划内存布局的结构类型，请参阅JimB的答案，并这个答案更详细和真实的例子。

7。另外，由于切片是标题，它们（几乎）总是按原样传递（无指针） 语言规范对指向切片的指针比指向数组的指针更严格。例如，该规范提供了用于指向数组的操作的多个shorthands，而在切片的情况下，这给出了编译时错误（因为很少使用指向slice的指针，如果您仍然需要/必须这样做，您必须明确的处理它;阅读更多在这个答案）。

这样的例子是：

• 将指针指向数组： p p [低：高] 是（* p）[低：高] 的简写。如果 p 是一个指向slice的指针，这是编译时错误（ spec：Slice expressions ）。




• 索引 p 数组： p [i] 是（* p）[i] 的简写。如果 p 是指向切片的指针，这是编译时错误（

    pa：=& [2] int {1，2} 
   fmt.Println（pa [1：1]）// OK 
   fmt.Println（pa [1]）//确定
   
   ps：=& [] int {3，4} 
   println（ps [1：1]）/ /错误：不能分片ps（类型* [] int）
   println（ps [1]）//错误：无效操作：ps [1]（type * [] int不支持索引）
    

  8。 访问（单个）数组元素更高效比访问切片元素;就像在切片的情况下一样，运行时必须通过隐式指针解引用。如果 len（s）和 cap（s）的表达式都是常量，那么 c $ c> s 是一个数组或指向数组的指针。
  
  

  可能会令人惊讶，但您甚至可以写：

    type IP [4] byte 
   
   const x = len（IP {}）// x将是4 
    

  它是有效的，并且被评估和编译时，即使 IP {} 不是常量表达式，例如 const i = IP {} 会是编译时错误！在这之后，下面的内容也不足为奇：
  
  

    const x2 = len（（* IP）（nil）） // x2也将是4 
    

  ^{注意：当遍历完整数组与完整数组切片，可能根本没有性能差异，因为显然它可以被优化，使得切片标头中的指针只被解除引用一次。有关详细信息/示例，请参阅数组与片段：访问速度。}

  
  
  

  ---

  
  
  

  请参阅相关问题，其中数组可以使用/更有意义：

  
  
  

  为什么使用数组而不是切片？ p>
  
  

  为什么在Go地图中不能使用Go slice作为关键字几乎与数组可以用作关键字的方式相同？

  
  
  

  使用密钥散列作为数组类型

  
  
  

  Golang：我如何检查三个值ele的相等性gantly？

  
  
  

  切片作为参数传递的切片指针

  
  
  

  这只是为了好奇： 切片可以包含自己，而数组不能。 （实际上这个属性使得比较更容易，因为你不必处理递归数据结构）。

  
  
  

  必读博客：

  
  
  

  Go Slices：用法和内部元素 p>
  
  

  数组，切片（和字符串）：append的机制'

  
  

  I understand the difference between arrays and slices in Go. But what I don't understand is why it is helpful to have arrays at all. Why is it helpful that an array type definition specifies a length and an element type? Why can't every "array" that we use be a slice?

  解决方案

  There is more to arrays than just the fixed length: they are comparable, and they are values (not reference or pointer types).

  There are countless advantages of arrays over slices in certain situations, all which together more than justify the existence of arrays (along with slices). Let's see them. (I'm not even counting arrays being the building blocks of slices.)

  ---

  1. Being comparable means you can use arrays as keys in maps, but not slices. Yes, you could say now that why not make slices comparable then, so that this alone wouldn't justify the existence of both. Equality is not well defined on slices. FAQ: Why don't maps allow slices as keys?

  They don't implement equality because equality is not well defined on such types; there are multiple considerations involving shallow vs. deep comparison, pointer vs. value comparison, how to deal with recursive types, and so on.

  2. Arrays can also give you higher compile-time safety, as the index bounds can be checked at compile time (array length must evaluate to a non-negative constant representable by a value of type int):

  s := make([]int, 3)
  s[3] = 3 // "Only" a runtime panic: runtime error: index out of range
  
  a := [3]int{}
  a[3] = 3 // Compile-time error: invalid array index 3 (out of bounds for 3-element array)
  

  3. Also passing around or assigning array values will implicitly make a copy of the entire array, so it will be "detached" from the original value. If you pass a slice, it will still make a copy but just of the slice header, but the slice value (the header) will point to the same backing array. This may or may not be what you want. If you want to "detach" a slice from the "original" one, you have to explicitly copy the content e.g. with the builtin copy() function to a new slice.

  a := [2]int{1, 2}
  b := a
  b[0] = 10 // This only affects b, a will remain {1, 2}
  
  sa := []int{1, 2}
  sb := sa
  sb[0] = 10 // Affects both sb and sa
  

  4. Also since the array length is part of the array type, arrays with different length are distinct types. On one hand this may be a "pain in the ass" (e.g. you write a function which takes a parameter of type [4]int, you can't use that function to take and process an array of type [5]int), but this may also be an advantage: this may be used to explicitly specify the length of the array that is expected. E.g. you want to write a function which takes an IPv4 address, it can be modeled with the type [4]byte. Now you have a compile-time guarantee that the value passed to your function will have exactly 4 bytes, no more and no less (which would be an invalid IPv4 address anyway).

  5. Related to the previous, the array length may also serve a documentation purpose. A type [4]byte properly documents that IPv4 has 4 bytes. An rgb variable of type [3]byte tells there are 1 byte for each color components. In some cases it is even taken out and is available, documented separately; for example in the crypto/md5 package: md5.Sum() returns a value of type [Size]byte where md5.Size is a constant being 16: the length of an MD5 checksum.

  6. They are also very useful when planning memory layout of struct types, see JimB's answer here, and this answer in greater detail and real-life example.

  7. Also since slices are headers and they are (almost) always passed around as-is (without pointers), the language spec is more restrictive regarding pointers to slices than pointers to arrays. For example the spec provides multiple shorthands for operating with pointers to arrays, while the same gives compile-time error in case of slices (because it's rare to use pointers to slices, if you still want / have to do it, you have to be explicit about handling it; read more in this answer).

  Such examples are:

  • Slicing a p pointer to array: p[low:high] is a shorthand for (*p)[low:high]. If p is a pointer to slice, this is compile-time error (spec: Slice expressions).

  • Indexing a p pointer to array: p[i] is a shorthand for (*p)[i]. If p is pointer to a slice, this is a compile time error (spec: Index expressions).

  Example:

  pa := &[2]int{1, 2}
  fmt.Println(pa[1:1]) // OK
  fmt.Println(pa[1])   // OK
  
  ps := &[]int{3, 4}
  println(ps[1:1]) // Error: cannot slice ps (type *[]int)
  println(ps[1])   // Error: invalid operation: ps[1] (type *[]int does not support indexing)
  

  8. Accessing (single) array elements is more efficient than accessing slice elements; as in case of slices the runtime has to go through an implicit pointer dereference. Also "the expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array".

  May be suprising, but you can even write:

  type IP [4]byte
  
  const x = len(IP{}) // x will be 4
  

  It's valid, and is evaluated and compile-time even though IP{} is not a constant expression so e.g. const i = IP{} would be a compile-time error! After this, it's not even surprising that the following also works:

  const x2 = len((*IP)(nil)) // x2 will also be 4
  

  ^{Note: When ranging over a complete array vs a complete slice, there may be no performance difference at all as obviously it may be optimized so that the pointer in the slice header is only dereferenced once. For details / example, see Array vs Slice: accessing speed.}

  ---

  See related questions where an array can be used / makes more sense than a slice:

  Why use arrays instead of slices?

  Why can't Go slice be used as keys in Go maps pretty much the same way arrays can be used as keys?

  Hash with key as an array type

  Golang: How do I check the equality of three values elegantly?

  Slicing a slice pointer passed as argument

  And this is just for curiosity: a slice can contain itself while an array can't. (Actually this property makes comparison easier as you don't have to deal with recursive data structures).

  Must-read blogs:

  Go Slices: usage and internals

  Arrays, slices (and strings): The mechanics of 'append'

  这篇关于为什么在Go中有数组？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！