Por que usar a semântica de ponteiro no iterador de loop resulta na referência ao mesmo valor? [duplicado]
Um exemplo simplificado que demonstra um caso de bugs encontrado com várias camadas:
// Store a list of boxed integers in map and print them.
// This prints 3 times the int value of 3.
type number struct{ val int }
func setInMap() map[int]*number {
list := []number{{1}, {2}, {3}}
m := make(map[int]*number)
for i, n := range list {
// when saving the address of n,
// all values point -> 3
m[i] = &n
}
return m
}
func main() {
m := setInMap()
for _, n := range m {
// Prints 3,3,3 or last set value when pointer
// instead of 1,2,3
fmt.Print(n.val, ",")
}
}
Link do Buggy Pointer Semantics Playground
Compare isso com salvar uma versão semântica de valor que funcione corretamente:
for i, n := range list {
// set -> map using value semantics
// prints all values
m[i] = n
}
Link Value Semantics Playground
Respostas
A razão é que a for..range
construção usa a semântica de valor, resultando no compilador copiando cada valor da lista para a pilha , ou seja, o conteúdo de int n
.
// n is copied into the stack at each iteration
for i, n := range list
Posteriormente, ao obter o endereço de n, estamos armazenando o endereço da mesma variável iterada da pilha.
// when saving the address of n,
// in a for..range loop we are taking the address of
// same iterated variable n in stack.
// resulting in the same value stored thrice in the map.
m[i] = &n
Para corrigir a versão semântica do ponteiro, use for i=
resultando na seguinte versão correta :
// n is now pointing to distinct
// members of the list in heap.
for i := 0; i < len(list); i++ {
n := &list[i]
m[i] = n
}
Como uma nota de desempenho lateral, isso melhora a eficiência, o que é importante para grandes n objetos , pois elimina a cópia ineficiente e imparcial para n objetos, mantendo objetos aninhados hierárquicos.
Playground (versão correta)