Thanks for this explanation, it does make sense (in particular you unsafe example showing that they are different pointers) technically.
It thus confirms that I am using method pointers in a "supported" by passing them around (in an interface) and expecting them to operate on their original struct independently. Sets me a bit back with finding the actuall error in my code though as I seem to see them sometimes operate one "the wrong struct" (which Is why I started printing the pointers using fmt to understand what was actually happening) - but there must be something else that I am missing. Would be interested to learn anything more you find out about the underrlying explanation though. /V On Saturday, December 9, 2017 at 2:48:11 PM UTC+1, Axel Wagner wrote: > > No, the question is actually, why methods bound to *different* pointers, > still print the same: > https://play.golang.org/p/o2lgZBBYx- > The same can be observed for closures (unsurprisingly): > https://play.golang.org/p/B6QKQWiraL > > I don't yet have a conclusive, detailed answer (I tried diving into the > code, but didn't find the right place), but the pointer that is passed > around isn't actually the pointer that is printed. You can see that in this > code, which unsafely casts a func() to an unsafe.Pointer: > https://play.golang.org/p/xmMm--Wxt3 > As you can see, different closures are passed as different actual pointers > in f. But fmt still prints them the same. It seems to unpack the actual > pointer to the code from the closure-struct (or rather, reflect is doing > that for fmt) for printing - which makes sense, if you are trying to debug, > I guess. And the value itself doesn't really have semantic meaning anyway > (as functions are not comparable). > > When calling the function literal, the compiler will then generate code to > a) dereference the pointer to the closure struct, b) unpack the arguments > from it and push them to the stack and c) call the function pointer > contained in the struct. > > You can also see this effect, when compiling a function that passes a > reference to a static function (say Foo) around. If you disassemble the > output (objdump -d) you can see in the code, that it doesn't pass a pointer > to Foo, but to a different function, which *then* calls Foo. > > On Sat, Dec 9, 2017 at 2:32 PM, Jakob Borg <ja...@kastelo.net > <javascript:>> wrote: > >> I confess I find the code a bit convoluted and hard to follow - but >> doesn’t it just boil down to method values bound to the same pointer, thus >> acting on the same struct value (state)? >> >> https://play.golang.org/p/VVdSyaYp5x >> <https://play.golang.org/p/FjP0FXTqTS> >> >> //jb >> >> >> On 9 Dec 2017, at 09:23, viktor...@gmail.com <javascript:> wrote: >> >> Hi, >> >> >> I have a problem that I have tried to reduce to a minimal re-producible >> example, I have not fully managed but it does show some to me strange >> behavior: >> >> >> https://play.golang.org/p/ZCyumUPBos >> >> >> I have a similar set up in a much larger set-up where I seem to see (no >> errors reported by race-detector) that sometimes inside a "actionWithState" >> the state is not remembered correctly/shared with other instances of >> "actionState"s. In this playground example however it always seems to >> behave as intended with each actionState's action method using its own >> state. In the example above however (I see the same thing) both actions >> *have >> the same address* when printed, how can that be that they behave >> differently if they point to the same data? >> >> >> I.e. I have two questions where I would appreciate tips since I cannot >> seem to wrap my head around it: >> >> 1. How can (in this code) actions[1] and actions[2] contain the same >> pointers (as seen by fmt.Print) yet behave differently when called as >> functions? >> >> 2. Although the behavior of the example above is what I expected (apart >> from it printing the same pointer value), is there any circumstance under >> which they would start to "share state" which I have not thought of that >> could lead to the problem I am seeing in my larger code-base that you could >> think of? >> >> >> Any thoughts appreciated :-) >> >> >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
