I recently switched from unity and I am wondering what are the cons of using UObjects instead of pure c++ plain old objects. Coming from a c# background I love the fact that unreal UObjects are managed, network propagated, etc. But do these capabilities come at a price?
In unity there are severe limitations to unity’s base Object class (equivalent to UObject) and I never used these for any calculations or algorithmes. For example Unity Objects do not work well in a multithreaded settings.
Do unreal UObject have notable limitations relative to plain c++ classes? Are there any nuiances in the following areas?
You’ve already partially answered your own question
Use UObject if you want to take advantage of engine features such as reflection, serialization, and networking, dynamic delegates, etc.
It depends. The overhead itself is not huge (an instance is ~60 bytes). Performance may be impacted by the fact that UObject can only be created on the heap via allocation. You don’t have much control over this, so individual instances can be scattered around memory.
The UObject constructor has a different purpose than the raw c++ constructor. The constructor is called indirectly by the engine, so it must have a predetermined signature, so you can’t create a constructor with your own parameters. The initialization of the object must be done in a separate function. Since the UObject lifetime is managed by the engine, you also don’t know when the destructor will be called, unlike in pure C++ where destructor is called automatically(out of scope) or explicit (by delete)
UObject is not thread-safe. You have to be very careful when operating UObject in a multi-threaded application.
Translated to C# - UObject is a reference type. It’s ok for creating abstractions or APIs, but algorithms are more performant when they operate on value types properly arranged in memory
