为什么count++(而不是count = count + 1)会改变Golang中返回地图的方式 [英] Why does count++ (instead of count = count + 1) change the way the map is returned in Golang

问题描述

我使用了一个映射，它使用句子中的单词作为键，整数作为值.

I used a map that uses words from a sentence as its keys and integers as the values.

func WordCount(s string) map[string]int {
    var m map[string]int
    m = make(map[string]int)
    var substrings[]string
    count := 0
    substrings = strings.Split(s, " ")
    for i := range substrings {
        count = count + 1
        m[substrings[i]] = count
    }

    return m
}

func main() {   
    fmt.Println(WordCount("I am learning GO since some days"))
}

上面的代码ALWAYS以正确的顺序显示地图，即

The above code ALWAYS displays the map in the correct order, i.e.

map[I:1 am:2 learning:3 GO:4 since:5 some:6 days:7]

但如果我改变了

count = count + 1

到

count++

输出变为:

map[learning:3 GO:4 since:5 some:6 days:7 I:1 am:2]

我知道在 Golang 中 map 迭代是随机的，但为什么 count = count + 1 总是导致 map 迭代以与 count++ 相反的有序方式返回?

I know that map iteration is random in Golang but why does count = count + 1 always cause the map iteration to be returned in an ordered fashion contrary to count++?

推荐答案

改变count变量值的方式与map元素的迭代顺序无关.

The way how you change the value of the count variable has nothing to do with the iteration order of the map elements.

p>

没有正确"的迭代顺序，迭代顺序可以被认为是随机的(在当前的实现中它是随机的).引用 语言规范:For statements:

There is no "correct" iteration order, the iteration order can be thought of as random (and in current implementation it is random). Quoting from the language spec: For statements:

未指定映射的迭代顺序，也不保证从一次迭代到下一次迭代顺序相同.

The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next.

有关该主题的更多信息，请查看以下答案:为什么不能按插入顺序迭代地图?

For more on the topic, check out this answer: Why can't Go iterate maps in insertion order?

Go Tour 使用 Go Playground 提供代码编辑器和运行器.Go Playground 缓存您在其上运行的代码的输出.运行两次完全相同的代码只会显示缓存的输出.

The Go Tour uses the Go Playground to provide a code editor and runner. The Go Playground caches the output of the codes you run on it. Running twice the exact same code will just show you the cached output.

但是，如果您更改了代码，则会将其视为"新代码，并且将被编译和运行(其输出将在之后被缓存).而且由于它是重新运行的，您可能会观察到一个新的随机顺序 - 您会这样做.

If you change your code however, that is "treated" as new code and it will be compiled and ran (and its output will be cached after). And since it is run anew, you may observe a new random order - which you do.

如果您再次更改代码中的某些内容，即使添加或更改某些注释微不足道，输出也会(可能)再次更改，请尝试一下.

If you change again something in the code, even as insignificant as adding or changing some comment, the output will (may) change again, try it.

有关 Playground 如何实现的更多信息，请参阅博文 Go Playground 内部.

For more information on how the Playground is implemented, see blog post Inside the Go Playground.

引用相关部分:

当前端收到编译请求时，它首先检查 memcache 以查看如果它缓存了该源先前编译的结果.如果找到，则返回缓存的响应.缓存会阻止流行的程序，例如 Go 主页上的程序 避免后端超载.如果没有缓存响应，则前端向后端发起 RPC 请求，将响应存储在 memcache 中，解析播放事件，将 JSON 对象作为 HTTP 响应返回给客户端(如上所述).

When the front end receives a compilation request it first checks memcache to see if it has cached the results of a previous compilation of that source. If found, it returns the cached response. The cache prevents popular programs such as those on the Go home page from overloading the back ends. If there is no cached response, the front end makes an RPC request to the back end, stores the response in memcache, parses the playback events, and returns a JSON object to the client as the HTTP response (as described above).

另请注意，从 Go 1.12 开始，地图在打印时使用fmt 包(以便于测试)，因此现在打印相同的地图将始终以相同的顺序列出元素.迭代顺序仍然故意保持非确定性.

Also note that starting with Go 1.12, maps are sorted when printed using the fmt package (to ease testing), so printing the same map now will always list elements in the same order. The iteration order still remains non-deterministic deliberately.

这篇关于为什么count++(而不是count = count + 1)会改变Golang中返回地图的方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！