Sorry to resurrect an old thread, but I just thought it worth mentioning that this is also the case if the key is a type from another package and the type contains an unexported pointer. Case in point: map[time.Time] <https://play.golang.org/p/iuVUfT6ZNT> I'm not sure how deep this goes - what if the pointer is 2 packages deep in the dependency graph? Would it not be equal in that case?
On Tuesday, March 12, 2013 at 7:28:51 PM UTC+13, Doug Fawley wrote: > > On Mon, Mar 11, 2013 at 1:03 AM, Jan Mercl <0xj...@gmail.com <javascript:> > > wrote: > >> I wonder, how DeepEqual manages cyclic data? Does >> it compare shapes of value-less node graphs? What about when given two >> different nodes of the same non oriented graph? The ad hoc >> [non]/dereferencing can get quite evil pretty fast. >> > > It looks like it maintains a set of visited addresses so it can > short-circuit computations if the same appears multiple times, which also > will stop you when cycles are encountered.. > > However, the documentation (http://golang.org/pkg/reflect/#DeepEqual) >> says the opposite: "It uses normal == equality where possible but will >> scan members of arrays, slices, maps, and fields of structs.". If it >> dereferences a pointer to a string and compare the dereferenced values >> instead then the docs are docs are not correct. >> > > It does say that it uses == if possible, which led me to assume the same > thing at first -- especially when coupled with my failing test case that I > believed should have passed. Might be nice to clarify in the doc string. > > On Mon, Mar 11, 2013 at 1:07 AM, Jesse McNelis <jes...@jessta.id.au > <javascript:>> wrote: > >> Still, I think the DeepEqual behavior question is valid and unresolved. >>> >> Since the keys aren't the string values and are instead the pointers to >> the string values this would allow two maps with completely different keys >> to be considered equal. That's seriously weird. >> > > Not any weirder than dereferencing other pointers and comparing by value, > except the implementation is harder. The *real *trouble comes in when > the map keys: 1. Are pointers to non-data types (could fall back to ptr > comparison in that case), or 2. Have duplicate data behind different > pointers. Case 2 is really hard to solve. Consider the case: > > m1[&"hi"] = 1 > m1[&"hi"] = 2 > m2[&"hi"] = 1 > m2[&"hi"] = 2 > > These are clearly equivalent, but to check this you need to compare all > combinations of m1's keys + m2's keys. And then imagine if the maps' > values were deep data structures instead of simple ints...it would get > expensive to recursively compare them in all combinations. > > OK, DeepEqual is probably good the way it is...but might be nice to > document this to prevent others from asking the same questions later. > > Thanks, > Doug > > -- 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.
