C++ Interfaces - Execute_FunctionName() vs FunctionName_Implementation()

Interfaces are probably for me one of the most clunky implementations in the Unreal framework in my opinion.

Straight question. I have a class called Foo. Foo has a function called DoThis().
I have an interface called IFooable which has a function DoThis();

Foo implements IFooable.

I know that in unreal I can’t say MyIFooObject->DoThis() (where MyIFooObject is an Interface variable). However… this is where I need some guidance because I can’t find a straight answer.

The way I learned unreal was I had to do MyIFooObject->DoThis_Implementation(); This seems fine but I also see the compiler sometimes throw and tell me I need to use MyIFooObject->Execute_DoThis() instead.

What are the differences here, and when should I use which?

1 Like

One is for calling the function one is for implementations.

Foo should override DoThis_Implementation, but you should never directly call an _Implementation function except as a Super:: call to include functionality from the parent type.

The Execute_ version is used to call the function and deals with all the annoying details with Blueprint implementations. You should call this like: IFooable::Execute_DoThis( Object ). That object shouldn’t be an interface variable, just a UObject* (or something convertible to one).

Lastly, if an interface could be implemented by Blueprint, you’ll need to avoid having interface variables like MyIFooObject because Cast<IFooable>( ) will return nullptr when the interface is implemented in blueprint. Instead you’ll have to use TScriptInterface<IFooable> as the type.

I don’t disagree, it’s all Blueprint’s fault. :wink:

There could be reasons why you specifically want to call the native implementation rather than call into the Blueprint, although I would expect they would be few and far between, but I wouldn’t say never.

I don’t know if maybe this has been fixed/changed in the time since this document was written, but it seems like it’s better to actually call IInterface::Execute_Whatever(ObjectPointer), as apparently TScriptInterface does suffer from the same issue as just trying to use a Cast … unless that has changed since this was written:

Yep I ran into the TScriptInterface fun a little while back. I have gotten into the habit of working with UObject* now when I have interfaced objects simply because the editor doesn’t barf over that. I have some TScriptInterface pieces being used, mainly just to hold references to objects that I expose as property in blueprint.

In this case almost my entire project is C++ code and I don’t really use blueprinting. The confusing is when I watch tutorials, so many people are teaching to use the _implementation version, which does work just fine in my project… but I see Execute_FunctionName() as well and wonder why there are two ways to do the same thing.

But I see it has to do with blueprints. Maybe my code works fine because its mostly C++ and doesn’t use blueprints except for things like materials.

Yeah, always and never can be pretty loaded. You’d need a pretty good reason for it.

Oh absolutely, the TScriptInterface does not provide any better access to the functions. It’s just for variables and you’d want to get the object from the variable to call ::Execute_. But it’s the type you’d have to use to properly restrict a function parameter that’s callable by blueprint.

Because they’re not two ways to do the same thing. There’s one way to implement the interface (overriding the _Implementation function) and one way to call it (using the static Execute function).

In that case you do have another option. In the UINTERFACE macro you can include meta=(CannotImplementInterfaceInBlueprint), this will prevent implementations in Blueprint and a lot of the weirdness that causes. Once you’ve done that, at least in C++, you can treat the interface as you would expect: declaring and overriding virtual functions (no _Implementation functions needed), casting to IFooable* works as expected in all cases, you can call the functions directly with a pointer to the interface and you can even make the functions BlueprintCallable to still use in Blueprint.

1 Like

This may be my ignorance from years and years in C# speaking here. In C# when I implement an interface, i simply say IInterfaceableObject.DoThis() and it executes the DoThis() function on the base object.

In Unreal i say IInterfaceableObject->DoThis_Implementation() and it seems to execute the DoThis() function on the object.

In Unreal if I say IInterfaceableObject->Execute_DoThis() it also seems to execute the DoThis() function which is where I drew that conclusion.

I’ll check that out. That seems to be the direction I want to go.

My project works right now via using the _Implementation() functions, I am just wondering why I’d use one over the other. It seems the answer is blueprints cause some craziness.

it’s my understanding that if you call _Implementation you’re only calling the native code, not any potential Blueprint overrides.

2 Likes

Thank you, that makes a ton of sense. If I were using Blueprints I can see why I’d want to call Execute in that case. As I’m not using Blueprints that won’t make a difference to me.

1000 thanks.

If you go that route, remember that months down the road when you think “oh, hey, i can just override this thing real quick in blueprint” and then nothing overrides :smiley:

1 Like

I’m one of those weird people that doesn’t like blueprints if I don’t have to use them, and prefer doing everything I can in pure code. However sometimes I’ve noticed I don’t have a choice so what you are saying is sage, because I can see that coming up should I have to go a blueprint route for whatever reason and trying to call interface functions that suddenly won’t override heh.