I have difficulties to understand when to use CreateSP versus CreateRaw versus CreateUObject.
I know that the way the delegate is created and returned is not exactly the same (Raw Pointer, SharedPointer, ??) but is there anyone that can explain why/when I should one instead of the others?
I just noticed that in Slate object, I can’t use CreateUObject and I suspect that’s because SlateWidget are not based on UObject. But I can use CreateRaw & CreateSP.
My goal is to implement some on the OnlineSubsystem interfaces directly in some Widget so I can put them anywhere in my UI Layout and it will work as it will be autonomous
CreateUObject is only usable with UFUNCTIONS, which are inside UObjects (as names implies).
CreateRaw is usable with everything, though I guess intenstion is to use it only with raw C++.
As for CreateSP I honestly don’t know. I never used it.
In this case, why not using CreateRaw anytime as it will work with everything including raw C++. I bet there are some tweaking and performance/memory thing behind this.
It could be great if anyone from Epic can highlight us on this.
Essentially yes, Create/BindRaw can be used widely, but it has the drawback that it does not reference the object whose member function is being bound. So if that object gets deleted the delegate will end up holding a dangling pointer. So you should only use it when you know for sure that the object will outlive the delegate binding.
If you use the shared pointer version (Create/BindSP), you can test it to check that the object still exists before executing. There are heaps of examples of using the SP version within the codebase.
Edit:
To clarify, the ‘Raw’ refers to a raw C++ pointer in contrast to a smart (shared) pointer. It still is restricted to use on a member function of a C++ class object, in the same way that SP is restricted to a member function of an object referenced by a shared pointer. Likewise the UObject version works on member functions but with the restriction that the (raw) pointer passed in is to a UObject derived type. The Static variant is different, it binds to a global function or class static method, such that it is not associated with any object at all.
O_o Thanks for the documentation link. I was looking for it and I wasn’t able to get it! I think I didn’t put the right terms into the doc search input.
I think I more clear on the topic.
Isn’t it usually more safe to use the SP version so a SharedPointer is set in the background for this delegate and we can’t have Dangling pointer?
If we are using BindRaw, we must be sure of the Object lifetime and properly manage unbind during destruction process, which is not bad but will also be a area of failure if something is missed.
