to be honest, i m killed because i agree 100% with that explanation. I friendly scratch my head too because i m less interested by the implementation than by the packaging you put on it, and the effects that it produces on the end user, if i can say so.
In that regards the explanation you gave can t help me to get that idea out of my head, i think. On Thursday, May 11, 2017 at 11:53:37 AM UTC+2, Chris Hopkins wrote: > > >> >> In this code, >> starting at 0, >> is case 1 not an aberration, >> is case 3 is useless >> https://play.golang.org/p/VyOfZyt7rw >> >> Note case 0 is expected to fail and might be detected. >> >>> >>> As a dumb hardware engineer I too have struggled with this in the past. > 2 rules I find helped: > 1) Everything into a function is passed as a copy > 2) If you need to modify something passed to you in a function then you > need not a copy of the thing but the address of the thing you want to modify > so taking your code for both cases 0 & 1: > func (v valueType) SetName(n string) { > v.Name = n > } > when this function runs a local bit of storage is created (probably on the > stack as escape analysis would determine that the value can't escape the > scope) and the current value of the data is copied into that storage. That > storage is then modified. The function then returns. The local storage goes > out of scope and you are left with your original data unchanged. > > for cases 2&3 > func (v *refType) SetName(n string) { > v.Name = n > } > This time again the function runs and there is a local piece of storage > created (again called v) this time the local storage (probably on the stack > as v cannot escape the scope of that function) and v gets the pointer to > the variable it was called on copied into it instead of the value. > So when you set the name it uses the local copy of the pointer to access > the Name field. Because this is pointing to the underlying storage for the > original structure that structure is modified. > What might be causing confusion here (because it used to confuse me with > go) is that go is doing something automatically under the hood. When you > type v.Name it knows that *refType does not have a field Name. It knows > that you're trying to access the structure addressed by the pointer and so > automatically de-references the pointer for you i.e. takes the address held > in v, works out what offset from that address it has to use to get at the > Name field and then directs the assignment to that new address. > > At least that's how I think it works. I'm sure someone will correct me, as > this would otherwise be the first time I had this low level detail of > software correct ;-) > > HTH > > Chris > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
