In the documentation (and in a lot of examples from the forums), I see UObjcts ceated with the constructor with signature className(const FObjectInitializer& ObjectInitializer); It even says it should be implemented like that. What bothers me is that when I create new c++ classs (actor, component, whatever), I get a constructor className(); by default.
I’m wondering if perhaps the const FObjectInitializer& ObjectInitializer version is something that had to be used in older engine versions but is no longer needed, or is the default created constructor wrong (or if there is something else I’m failing to take into account).
Also, i someone could explain in brief what FObjectInitializer thingy does, I’d appreciate it.
Granted I am nearly as much of a novice as you are, but my experience has been that both constructors are valid. FObjectInitializer& is a reference to an object that can instantiate subobjects in the constructor. The parameterless constructor can be used when you have no need to instantiate any subobjects in the constructor.
Yep, it’s largely a legacy thing. Until one or two versions ago, the object initializer was required for creating subobjects. Then Epic added that functionality directly into the UObject class, and allowed constructors with no arguments.
I believe the object initializer is still required in the particular case that you need to customize the type of subobject created by a base class, from within a derived class (see FObjectInitializer::SetDefaultSubobjectClass). For example, if you derive a class from ACharacter and what to modify the type of movement component used.
@Davor: A subobject is essentially a UObject that is created by and exists within another object. An actor component is a subobject, and often the two are used interchangeably, but subobjects do not have to be actor components.
Yeah, if B is a subobject of A, then the outer of B will be A. I don’t know if Epic has a strict definition of what constitutes a subobject, it may imply also that B exists within A from construction, as opposed to being created dynamically later on, but I’m not sure. The outer relationship is the main thing anyway.
Ah, thank you again, it’s beginning to make sense!
If I may further ask, what does outer imply? As far as I’ve managed to get from the forums, except for the hierarchy structure, all it does is keep the outer from getting garbage collected.
Now you’re going beyond my knowledge
I have heard that it’s a bit of a legacy thing from older versions of the engine, so perhaps it doesn’t have the significance it used to, I’m not sure.
As you say, all objects hold a UPROPERTY reference to their outer, which means that an outer can never be garbage collected while any of it’s ‘inners’ are still around.
I would guess that it also plays a role in the UObject loading process in terms of dependency ordering.
In practice though, I think all that really matters is to think of it as a kind of ownership relation, so when you create an object, set its outer based on what other object best fits the concept of an ‘owner’ in that context.
