为什么列表在 Go 中很少使用? [英] Why are lists used infrequently in Go?

问题描述

我是 Go 的新手，对此非常兴奋.但是，在我广泛使用的所有语言中:Delphi、C#、C++、Python - 列表非常重要，因为它们可以动态调整大小，而不是数组.

I'm new to Go, and quite excited about it. But, in all the languages I've worked with extensively: Delp C#, C++, Python - Lists are very important because they can be dynamically resized, as opposed to arrays.

在 Golang 中，确实有一个 list.List 结构，但我很少看到关于它的文档 - 无论是在 Go By Example 或我拥有的三本围棋书籍 - Summerfield、Chisnal 和 Balbaert - 他们都花了大量时间在数组和切片上，然后跳到地图.在源代码示例中，我也发现很少或根本没有使用 list.List.

In Golang, there is indeed a list.Liststruct, but I see very little documentation about it - whether in Go By Example or the three Go books that I have - Summerfield, Chisnal and Balbaert - they all spend a lot of time on arrays and slices and then skip to maps. In souce code examples I also find little or no use of list.List.

看起来，与 Python 不同的是，List 不支持 Range - IMO 的一大缺点.我错过了什么吗?

It also appears that, unlike Python, Range is not supported for List - big drawback IMO. Am I missing something?

切片当然很好，但它们仍然需要基于具有硬编码大小的数组.这就是 List 的用武之地.有没有办法在没有硬编码数组大小的情况下在 Go 中创建数组/切片?为什么列表会被忽略?

Slices are certainly nice, but they still need to be based on an array with a hard coded size. That's where List comes in. Is there a way to create an array /slice in Go without a hard coded array size? Why is List ignored?

推荐答案

我在几个月前问过这个问题，当时我刚开始研究 Go.从那以后，我每天都在阅读有关 Go 的文章，并使用 Go 进行编码.

I asked this question a few months ago, when I first started investigating Go. Since then, every day I have been reading about Go, and coding in Go.

因为我没有收到这个问题的明确答案(虽然我已经接受了一个答案)我现在要根据我所学到的知识自己回答这个问题:

Because I did not receive a clear-cut answer to this question (although I had accepted one answer) I'm now going to answer it myself, based on what I have learned, since I asked it:

有没有办法在没有硬编码的情况下在 Go 中创建数组/切片数组大小?

Is there a way to create an array /slice in Go without a hard coded array size?

是的.切片不需要硬编码数组来slice from:

Yes. Slices do not require a hard coded array to slice from:

var sl []int = make([]int,len,cap)

此代码分配切片 sl，大小为 len，容量为 cap - len 和 >cap 是可以在运行时分配的变量.

This code allocates slice sl, of size len with a capacity of cap - len and cap are variables that can be assigned at runtime.

为什么 list.List 被忽略了?

list.List 在 Go 中似乎很少受到关注的主要原因是:

It appears the main reasons list.List seem to get little attention in Go are:

• 正如@Nick Craig-Wood 的回答中所解释的那样，有对于无法完成的列表，几乎没有任何事情可以完成切片，通常更有效，更清洁，更优雅的语法.例如范围构造:

• As has been explained in @Nick Craig-Wood's answer, there is virtually nothing that can be done with lists that cannot be done with slices, often more efficiently and with a cleaner, more elegant syntax. For example the range construct:

for i:=range sl {
  sl[i]=i
}

不能与列表一起使用 - 需要 C 风格的 for 循环.而在许多情况下，C++ 集合样式语法必须与列表一起使用:push_back 等

cannot be used with list - a C style for loop is required. And in many cases, C++ collection style syntax must be used with lists: push_back etc.

也许更重要的是，list.List 不是强类型的——它与 Python 的列表和字典非常相似，允许在集合中混合各种类型.这似乎相反对事物的 Go 方法.Go 是一种非常强类型的语言 - 例如，Go 中从不允许隐式类型转换，即使是从 int 到 int64 的 upCast 也必须是明确的.但是 list.List 的所有方法都采用空接口 -什么都可以.

Perhaps more importantly, list.List is not strongly typed - it is very similar to Python's lists and dictionaries, which allow for mixing various types together in the collection. This seems to run contrary to the Go approach to things. Go is a very strongly typed language - for example, implicit type conversions never allowed in Go, even an upCast from int to int64 must be explicit. But all the methods for list.List take empty interfaces - anything goes.

我放弃 Python 而转向 Go 的原因之一是因为Python 类型系统中的这种弱点，尽​​管 Python声称是强类型"(IMO 不是).Go的list.List好像成为一种杂种"，诞生于 C++ 的 vector 和 Python 的List()，在 Go 本身中可能有点不合适.

One of the reasons that I abandoned Python and moved to Go is because of this sort of weakness in Python's type system, although Python claims to be "strongly typed" (IMO it isn't). Go'slist.Listseems to be a sort of "mongrel", born of C++'s vector<T> and Python's List(), and is perhaps a bit out of place in Go itself.

如果在不久的将来的某个时候，我们发现 list.List 在 Go 中已被弃用，我不会感到惊讶，尽管它可能会保留，以适应那些罕见情况，即使使用良好的设计实践，一个问题可以通过包含各种类型的集合来最好地解决.或者，也许它可以为 C 系列开发人员提供一个桥梁"，让他们在学习切片的细微差别之前熟悉 Go，AFAIK.(在某些方面，切片似乎类似于 C++ 或 Delphi 中的流类，但并不完全如此.)

It would not surprise me if at some point in the not too distant future, we find list.List deprecated in Go, although perhaps it will remain, to accommodate those rare situations where, even using good design practices, a problem can best be solved with a collection that holds various types. Or perhaps it's there to provide a "bridge" for C family developers to get comfortable with Go before they learn the nuances of slices, which are unique to Go, AFAIK. (In some respects slices seem similar to stream classes in C++ or Delp but not entirely.)

虽然来自 Delphi/C++/Python 背景，但在我最初接触 Go 时，我发现 list.List 比 Go 的切片更熟悉，因为我对 Go 越来越熟悉，我已经回去并将我所有的列表更改为切片.我还没有发现 slice 和/或 map 不允许我做的任何事情，所以我需要使用 list.List.

Although coming from a Delphi/C++/Python background, in my initial exposure to Go I found list.List to be more familiar than Go's slices, as I have become more comfortable with Go, I have gone back and changed all my lists to slices. I haven't found anything yet that slice and/or map do not allow me to do, such that I need to use list.List.

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