The right way to override UFUNCTION

Development Programming & Scripting C++
1

Howdy!

I am building UT from scratch with UE4.22. That means it includes generating appropriate changes in the code. In my journey, I encounter several warnings and errors that UBT/UHT spit out while parsing the code. One issue which poses a dilemma is the error of type



 Override of UFUNCTION in parent class "SomeClass" cannot have a UFUNCTION() declaration above it; it will use the same parameters as the original declaration.

Epic’s default advise can be easily accessed in HeaderParser.cpp which says



Native function overrides should be done in CPP text, not in a UFUNCTION() declaration (you can't change flags, and it'd otherwise be a burden to keep them identical)

which kind of makes sense but when you actually implement this methodology, which is (I think) removing the keyword UFUNCTION in the .h declaration of the function and writing in the .cpp, the function no longer remains UFUNCTION().

Hence I was wondering what is the right way to declare the overriding UFUNCTION().

Thanks!

2

UFUNCTION() can only exist in a header file, it will do nothing in a CPP file. You also cannot add UFUNCTION() to an overridden function, you just override it as if it was a native function.

Put simply in this case, you don’t need to/can’t use UFUNCTION.

2 Likes
3

OK. Apparently it wasn’t the issue in earlier versions of the Engine because UT certainly has several “instances” of these overriding methods.

4

I’m sure this would have always been an issue, as the compiler would struggle to understand what to do if you gave a UFUNCTION() different params in the child class:

class A:
UFUNCTION(BlueprintImplementableEvent)
void SomeFunction();

class B : A
UFUNCTION(BlueprintNativeEvent)
void SomeFunction();

The compiler wouldn’t know what kind of blueprint style event to create here and I’m assuming get confused.

5

yeah, overriding a UFUNCTION definition has always been done by just… overriding the function, not declaring UFUNCTION again.

6

Well technically no one can really stop me from coding the Engine in such a fashion that it learns to give priority to the params of child classes. If it hasn’t been done in the Engine till now, then it is different issue. All I am saying that it no longer remains UFUNCTION() which is a concern for pedantic coder like me.

7

It hasn’t ever been supported and the reflection system will not support it.

Once the UFUNCTION is declared in a parent class, children will inherit it with the same parameters. It’s always worked that way but for some reason the warnings only stop compilation in more recent versions of UE4.

The generated code for the UFUNCTION exists in the parent class inside GENERATED_BODY(), which means children inherit that. Declaring the same UFUNCTION in a child class wouldn’t make sense.

8

Ok here is a simple test to test that theory. Open HeaderParser.cpp file in UnrealHeaderTool/Private and jump on to line 6838 (just after FString coms = FuncInfo.Function.Identifier) and add the code


UE_LOG(LogTemp, Warning, TEXT("+ Detected UFUNCTION() %s in class %s"), FuncInfo.Function.Identifier, *SuperStruct->GetFullName());

Compile it with UBT.

Now try the example of child class (one being overridden UFUNCTION() and other not). UHT won’t detect the child class UFUNCTION() if not mentioned in the header (but that will ofcourse generate the error mention in the first post if you do mention)