You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This time, the addValue function doesn't take effect on the s slice in main function. That's because it just manipulate the copy of the s, not the "real" s.
From https://golang.org/doc/effective_go.html?#slices we know that what happens here is that the value s, containing a pointer to an underlying array, is copied when passed as an argument to addValue.
In order to distinguish the two values, let's call the copy of s that exists within addValuecs.
When we use append to update cs, it just so happens that the capacity of the underlying array is exceeded. A new array is allocated, the values from the old array is copied to the new array, and the pointer in cs is updated to point to the new array.
Since our changes to cs are not reflected in s, the pointer to the underlying array in s is not updated and therefore points to the old array. This is the effect you show in your example.
If the underlying array happens to have enough capacity to accommodate the appended data, append actually does append data to the underlying array that s points to. See an example here: https://play.golang.org/p/eLQ9doxuWze
We see that s "is not aware" that more data has been added to the underlying array. If we want to read all of the data of the underlying array, we have to read beyond the length (not capacity) of the array. This is because the length is stored as a value in s, which is updated in cs during append, but, for the same reasons as with the updated pointer to the underlying array above, this change is not reflected in s.
The text was updated successfully, but these errors were encountered:
Hello,
Thank you for sharing your knowledge with the rest of the community!
I was looking at your explanation of passing slices as function argumens (https://github.com/NanXiao/golang-101-hacks/raw/master/posts/pass-slice-as-a-function-argument.md) and found that it may be nice to expand on it a bit:
From https://golang.org/doc/effective_go.html?#slices we know that what happens here is that the value
s
, containing a pointer to an underlying array, is copied when passed as an argument toaddValue
.In order to distinguish the two values, let's call the copy of
s
that exists withinaddValue
cs
.When we use
append
to updatecs
, it just so happens that the capacity of the underlying array is exceeded. A new array is allocated, the values from the old array is copied to the new array, and the pointer incs
is updated to point to the new array.Since our changes to
cs
are not reflected ins
, the pointer to the underlying array ins
is not updated and therefore points to the old array. This is the effect you show in your example.If the underlying array happens to have enough capacity to accommodate the appended data, append actually does append data to the underlying array that
s
points to. See an example here: https://play.golang.org/p/eLQ9doxuWzeWe see that
s
"is not aware" that more data has been added to the underlying array. If we want to read all of the data of the underlying array, we have to read beyond the length (not capacity) of the array. This is because the length is stored as a value ins
, which is updated incs
duringappend
, but, for the same reasons as with the updated pointer to the underlying array above, this change is not reflected ins
.The text was updated successfully, but these errors were encountered: