为什么count ++（而不是count = count + 1）改变了Golang中地图的返回方式 [英] Why does count++ (instead of count = count + 1) change the way the map is returned in Golang
问题描述
我使用了一个地图，它使用一个句子中的单词作为其键和整数作为值。
$ b
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：=范围子字符串{
count = count + 1
m [substrings [i]] = count
}
return m
}
$ func main（）{
fmt.Println（WordCount（我正在学习GO，因为有些日子））
}
以上代码 ALWAYS 以正确的顺序显示地图，即
map [I：1 am：2 learning：3 GO：4 since：5 some：6 days：7]
但是如果我改变
count = count + 1
$ p $
$ $ $ $ $ $ $ $ $ $ $ $ b 输出变为：
map [learning：3 GO：4 since：5 some：6 days：7 I：1 am：2]
我知道在Golang中映射迭代是随机的，但为什么 count = count + 1 总是导致返回映射迭代按照有序的方式，与 count ++ ？
改变 count 变量的值与地图元素的迭代次序无关。
没有正确的迭代次序，迭代次序可以被认为是随机的（并且在当前实现中它是随机的）。引用语言规范：For statements ：
映射上的迭代次序没有被指定，并且不能保证从一次迭代到下一次迭代是相同的。
有关该主题的更多信息，请查看以下答案：为什么不能按插入顺序执行迭代映射？
旅程使用 Go Playground 提供代码编辑器和跑步者。 Go Playground缓存您在其上运行的代码的输出。运行两次完全相同的代码只会显示缓存的输出。
如果您更改了代码，则将其视为新代码，并将其编译并运行（并且其输出将被缓存）。因为它是重新运行的，所以你可能会观察到一个新的随机顺序 - 你做了什么。
如果你再次改变代码中的某些东西，即使与添加或改变无关一些评论，输出将（可能）再次改变，尝试它。
有关如何实施Playground的更多信息，请参阅博客文章 Go Go Playground内部 。
引用相关部分：
当前端收到编译请求时，它首先检查 memcache 查看是否缓存了该源的先前编译结果。 如果找到，它将返回缓存的响应。缓存可防止流行的程序，如 Go首页超负荷后端。如果没有缓存响应，则前端向后端发出RPC请求，将响应存储在内存缓存中，解析播放事件，并将HTTP响应作为HTTP响应返回给客户端（如上所述）。 p>
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"))
}
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]
But if I change
count = count + 1
to
count++
The Output changes to:
map[learning:3 GO:4 since:5 some:6 days:7 I:1 am:2]
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++?
The way how you change the value of the count variable has nothing to do with the iteration order of the map elements.
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?
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.
For more information on how the Playground is implemented, see blog post Inside the Go Playground.
Quoting the relevant part:
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).
这篇关于为什么count ++（而不是count = count + 1）改变了Golang中地图的返回方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
