Hey Epic Friends!
FWeakObjectPtrs are great because they hold onto an ObjectIndex and ObjectSerialNumber that can uniquely identify an object that has ever existed during this run of the process. As such, they can be handy as keys in maps where you don’t want to hold a strong reference that keeps an object around OR where you want to be able to look things up even after the object has been garbage collected. However, some of this behavior is broken by the fact that operator== actually reports that two weak object pointers are the same, just because they happen to point to unloaded / garbage collected objects. Do you know why this is? What bad thing would happen if I removed that functionality and truly only returned true from operator== if the ObjectIndex and ObjectSerialNumber are the same?
(You may say, hey, don’t use FWeakObjectPtrs then, use lazy object pointers or something else. That would be nice, but I have reasons connected to other bits of the engine that are forcing me to use weak object ptrs and it would be a large amount of divergence to change. So if it’s possible for me to just strip the (!IsValid() && !Other.IsValid()) bit of the check, that would be great. I just don’t know where to begin confirming that that doesn’t breaking something secret and terrible…)
Thanks very much!!
Josh
Hello there,
Looking at the code, and comments above the operator==, this check is to maintain consistent behaviour between Ptr1 == Ptr2 and Ptr1.Get() == Ptr2.Get().
I would probably avoid breaking that assumption. Searching on that symbol is rather challenging, and there may be templated uses that remain even then that would require that assumption to hold.
Instead, you may be able to pass a custom KeyFuncs to the TMap that performs a check without the IsValid checks. FNaniteRasterEntryKeyFuncs should give an example of how that is performed.
The function HasSameIndexAndSerialNumber should already achieve the comparison I believe you are seeking. There are upstream changes to the comparison under the hood, so that’s probably the safest way to handle things.
I hope that helps.
Best regards,
Chris
Thanks! Yeah KeyFuncs are working well for us, but I’m just worried about other spots I might be missing. Sounds like the reasons for the change to operator== are too deep to know about fully so we’ll stick with making the surgical switch to HasSameIndexAndSerialNumber where it we notice it necessary.
thanks again!
Josh
You’re very welcome.
If you have any further questions, please feel free to ask. Otherwise, would you mind if I close this case out for now?
Best regards,
Chris
Awesome. I’ll close this out now.
Best regards,
Chris