In this particular case, couldn't you just check for len(m) == 0 ? i.e. assume that any zero size map is the shared one?
On Sat, 14 Mar 2020, 01:46 , <dtrac...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/golang-nuts/4c7dae4c-0420-485e-93f4-d13d6497a379%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/CAJhgacgSpA2Aqr7U_K%3DypMQMszOAKKsA86%3DBqz0eTwSZSdgEMw%40mail.gmail.com.
