The current implementation of the UObject construction pipeline requires the use of the NewObject function, but this precludes us from using UObject constructors that accept arguments. This approach requires us to use a separate ‘Init’ function, and to remember to call it whenever we create one of these objects, which to me is a little scary and certainly not conducive to safety. The better option, in terms of writing a tight, bug-free interface, is to be able to force the subclass to accept certain arguments upon construction so that it can’t exist without them (especially if those arguments are references, which can’t be null), as one would do in standard C++.
It would be amazing to have NewObject (or similar) looked at, and seeing if the process can be changed in some way to accept a variadic number of arguments, which can then be passed on to the UObject’s constructor. This would allow for a much cleaner construction/initialization interface for UObject subclasses.
Also, is it not impossible to have member variables that are const references and similar, since their value must be set in the initialization list of a constructor? Same with types that can’t be moved, copied, or assigned… you just can’t use them with UObjects at all!
Alternatively, if a developer says that it’s not too crazy (I had a dig through the pipeline and there’s a lot of things going on!), it might be worth looking at for a PR. Interested to hear your thoughts!
There has to be some technical reason why this isnt already implemented though right? I mean its something pretty big that seems reasonably obvious so it makes sense there is some reason Epic hasnt done this already. I can certainly see the benefits in being able to do this though so Im curious to hear more.
Oh yeah, that may well be the case! Or it’s just something that hasn’t seen much demand and so is considered not to be worth it (partly perhaps due to some people not even knowing it’s an option in ‘standard’ C++, which is scary in its own way ). This would be a fantastic change for code design in UE4, though.
I just wonder how the current construction process plays with the million different paths and configurations that may lead to it - editor, game, different platforms, cooking, cloning, default objects, etc. Maybe it’s easy, maybe it’s insane. I’d love to find out.
Well it would translate through to Blueprints too I imagine and might open up some of that const stuff there thats why Im curious as I dont work with C++ a whole lot. I see questions quite alot about passing data between BPs and people dont seem to understand Spawn, Construction, etc very well, its kind of this abstract process that doesnt really flow through like this would enable. Being able to pass parameters directly at spawn, which you can kinda do in a round abouts way and there are options like as you say an Init() function.
It could come down to complexity for not enough reward, thats certainly a possibility that its just not worth breaking the entire engine over. It could be that its not easy to implement along side and would require a very large refactor so that may be the case. What I was thinking though is why it wasnt added in originally back when UE4 was still in its early days, if it was considered or perhaps they just rolled with it and now here we are and its too costly to move forward on.
As far as I understand it the main reason that you cant have custom constructors in your UObjects is the reflection system and some default allocations.
Thats whyt the engine crashes if you try to create a UObject (member) instance in the constructor of onother UObject class.
Personally, I dont like the post construction “Initialize” skit either, but hey, thats how Unreal# (I refuse to call it C++ ) is.
What also is a pity: The Unreal header parser only picks up UFUNCTIONS by name and cares a **** about parameters, thus you cant overload UFUNCTIONS.
I would love this option more than custom constructors
). This would be a fantastic change for code design in UE4, though.
) is.