As mentioned above, I am wondering what are the advantages and disadvantages of using UPROPERTY() macro over variable without UPROPERTY() macro?
Also , I more or less know when to use UPROPERTY() , but I would like to know when not to use or when there is no need to use ?
Thank you.
The UPROPERTY macro informs the engine the variable exists for the purposes of garbage collection, and the statements inside the macro tell Blueprints and the editor how to interact with the variable.
The only reason not to use the UProperty macro is if the variable type isn’t exposed to Blueprint.
does the variable not using UProperty macro doesn’t need to go through garbage collection?
UPROPERTY() macro by it self is just dummy, this macro is marker for different tool called UnrealHeaderTool. UHT generates code before compilation that registers the variables (UPROPERTY), functions (UFUNCTION) class (UCLASS), structs (USTRUCT) etc. with extra meta data (that you add to that macro) to the UE4 reflection system.
C++ code is transformed in compilation process to CPU machine code and all varables object classes etc. don’t physicly exist there they striped from there body, all variables are converted to memory addresses, classes and structs are just memoery stractures which are accessed as normal varbales etc. because of that code it self is not aware of it’s own structure, don’t see it self, thats why it need reflection system in order to identify it’s own elements, byt for example by assigning names to specific memory addresses which later can be discovered and referenced in user interface (like property editor in UE4 editor) and UE4 has such system and those macros and UHT is part of it which tracks those varables before compilation and generates code that registers those, allowing UE4 to create kind of like map of it self, creating all those UClass* object that you interact in the code
If specific macro is missing that variable, class etc. won’t be visible to the engine and any memory management system that it has, it’s became pure C++ varable and needs to be managed manually like in pure C++, also some features require elements that are visible in UE4 reflection system in order to be used in them, for example functions that are used in UE4 timers need to be visible in reflection system and have that UFUNCTION(). And yes this naturally means that those variables are not cleaned by memory management, you need to manage them manually.
Some types are not supported by reflection system (like pointers to non-UObjects types), so you are forced to remove UPROPERTY() and manage them manually if you really want to use them. Also UCLASS() works only with UObjects and all UObjects need UCLASS() or else they will be broken and won’t work because engine needs to see them in order for them to work properly.
it needs to but without marking it as a uproperty you’ll have to take care of freeing the variable yourself, using delete or free in c/c++
Not using the UPROPERTY macro does not mean it doesn’t need garbage collection, it only means Unreal can’t do garbage collection and you’ll need to manage the memory yourself. One of the biggest reasons to always use UPROPERTY whenever available is to avoid memory leaks.
If you are defining the members of a UClass or UStruct, and you can use UPROPERTY, then you should use UPROPERTY.
If you can’t use UPROPERTY, they you need to make sure you account for memory allocation and freeing, otherwise you’ll develop memory leaks. If you’re not using a native UE4 type, you should definitely look into exposing your custom data type to Unreal and Blueprint via UClass, UEnum, UStruct etc.
Above you worte
“functions that are used in UE4 timers need to be visible in reflection system and have that UFUNCTION(). And yes this naturally means that those variables are not cleaned by memory management, you need to manage them manually.”
Doesn’t that appears a bit contradictory when compared to what’s stated in previous lines. Or is it that there are some functions which even after being declared with UClass macro doesn’t automatically go through garbage collection and hence have to be dealt manually.
His sentence structure is a bit confusing here. Read “also some features require elements that are visible in UE4 reflection system in order to be used in them, for example functions that are used in UE4 timers need to be visible in reflection system and have that UFUNCTION()” as a complete aside there:
“If specific macro is missing that variable, class etc. won’t be visible to the engine and any memory management system that it has, it’s became pure C++ varable and needs to be managed manually like in pure C++… yes this naturally means that those variables are not cleaned by memory management, you need to manage them manually.”
He’s saying if the UPROPERTY macro for a property, or the UCLASS macro for a class, or the UFUNCTION macro for a function isn’t present (“specific macro is missing”) then the engine can’t build that element into the reflection system. There are certain aspects of the engine that rely on the reflection system to operate, so, for example, a timer can’t work with a function that doesn’t include a UFUNCTION macro.
Variables/properties that don’t include the UPROPERTY macro can’t be included in the garbage collection system, and “must be managed manually like in pure C++”
I really appreciate the help , Thank you all.