I have a use for this that is not covered it seems. So basically I am runnning a code that may or may not create a map depending on if it needs to fill it with items. However I always need a map that is initialized in future downpath code. ( i use it in a range statement that just noops if it is empty) This code has to be optimized in the initial creation. less so for when i use it.
So the goal i was looking for was to always set a shared instance "Empty" map then when i need to fill it i check if the value is the empty map pointer and if so replace it with a brand new instance. That way all instances are lazy created and saves memory. This would be happening hundreds of thousands of times so even small performance improvements end up looking big at the end. if somebody has an alternative lazy initialization method that does not require pointer checks then i can use that instead. On Wednesday, February 12, 2020 at 8:11:44 AM UTC-8, Jake Montgomery wrote: > > The playground is your friend: https://play.golang.org/p/p10XugRD4_z > So, the answer is no. > > On Tuesday, February 11, 2020 at 6:56:05 PM UTC-5, Kevin Regan wrote: >> >> Would something like this work: >> >> m1 := make(map[string]string) >> m2 := m1 >> >> if &m1 == &m2 { >> ... >> } >> >> >> On Tue, Feb 11, 2020 at 5:50 AM roger peppe <rogp...@gmail.com> wrote: >> >>> I believe that the main reason that equality isn't defined on maps (and >>> slices) is to preserve the future possibility that equality might work at a >>> whole-value level rather than on a reference level. I suspect that one of >>> these days a final decision will be made... >>> >>> >>> On Mon, 10 Feb 2020 at 23:42, 'Kevin Regan' via golang-nuts < >>> golan...@googlegroups.com> wrote: >>> >>>> I just ran into this... ...makes me like go a little less. >>>> >>>> >>>> On Tuesday, August 7, 2018 at 6:34:03 AM UTC-7 mi...@daglabs.com wrote: >>>> >>>>> Sorry for bumping a very old thread, but I absolutely disagree with >>>>> the people stating that this problem is contrived, and I got here from a >>>>> Google search, so this might be relevant for some people. >>>>> >>>>> A very real use-case for reference-comparing maps is when testing >>>>> .Clone() methods. You want to make sure that the clone is an actual >>>>> clone, >>>>> and that all the properties of the cloned object are also a clone, etc. >>>>> In >>>>> these cases you want to reference-compare everything. >>>>> >>>>> That said, reflect.ValueOf(xxx).Pointer is more than sufficient for >>>>> this use-case. >>>>> >>>>> >>>>> On Monday, July 15, 2013 at 3:50:01 AM UTC+3, Yi DENG wrote: >>>>>> >>>>>> There're always something that is not comparable. You can consider >>>>>> map as one of this. If you have to check, use the pointer form. >>>>>> >>>>>> David >>>>>> >>>>>> On Saturday, July 13, 2013 7:35:55 PM UTC+8, Jsor wrote: >>>>>>> >>>>>>> I ask for maps because for slices this seems potentially >>>>>>> problematic: what does "same reference" entail for a slice? Overlapping >>>>>>> underlying arrays? Same starting pointer regardless of whether >>>>>>> their len matches? Same start, end, len, and cap? And so on. Though I >>>>>>> guess >>>>>>> "reference-equality" would be pretty well defined for channels. >>>>>>> >>>>>>> However, for maps determining "sameness" at a reference level seems >>>>>>> like a much more well defined question, and a much simpler one to >>>>>>> answer. >>>>>>> Yet I can't figure out a good way to do it. Perhaps with >>>>>>> reflect.Value.UnsafePointer (would that even work)? Either way, that >>>>>>> seems >>>>>>> like overcomplicating things. The "easiest" way to do it seems to be >>>>>>> something like this, dreamt up on the go-nuts IRC when I asked this: >>>>>>> http://play.golang.org/p/6Ffxfx7zBb >>>>>>> >>>>>>> But I think we can all agree that that's a rather silly and limited >>>>>>> solution (and to be fair wasn't suggested in earnest). >>>>>>> >>>>>>> I can see why == isn't defined on maps, too many people would likely >>>>>>> mistake it for a deep equality test (if that was indeed the reason), >>>>>>> but it >>>>>>> seems like there should be some semi-trivial way to see if two map >>>>>>> variables refer to the same map. Perhaps a need just wasn't seen for >>>>>>> such >>>>>>> an operation? Maybe it's really a more difficult/expensive test than I >>>>>>> assumed? >>>>>>> >>>>>> -- >>>> 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 golan...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/a1f4e265-4523-41be-a67a-f43610fd430a%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/a1f4e265-4523-41be-a67a-f43610fd430a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4c7dae4c-0420-485e-93f4-d13d6497a379%40googlegroups.com.
