UScript to UC++ questions.

DISCLAIMER - Regardless what could look, this is an “I know nothing, could you explain please?” post.


To the point, to understand/learn something I usually make some analogy to previously known things, and specially when studying a software upgrade my first comparisson is regarding the previous version.
I consider that I knew one or two things on UDK, but when Epic offered the chance of getting my fingers upon engine code U4 automatically looked like a better option, exactly because I reached a point where I was interested on “more power”. Well, consider that I’m on that “phase” where I did the discover that most of my previous UScript/U3 knowledge was almost useless… Or maybe not, so I did this post to go on posting suppositions that if confirmed or denied and explained could help me a lot on put my previous game prototype up and running again.

I fear on made suppositions, assume then as truth and make mistakes, so if I get some theories checked I can proceed by my own, so if you could collaborate I’ll thank you comming back fewer times with more “lame” questions! :smiley:

QUESTION 1: Does has the object constructor (that PCIP thing or a custom constructor) the role as the old Uscript DefaultProperties bottom field?

C++ doesn’t supports work with non-initialized variables (well, it’s what VS says everytime I try), the objects that need be on the instance since creation should be built on the Constructor (QUESTION 2), but, what about temporary objects’ variables as the ones created/used internally by functions?

Most objects I try to create on functions shoots the compiler error about no default constructor so, the new( ) fails on most childs from UObjects, on Uscript you could just shoot a local (optional auto?) keyword variable (QUESTION 3) and proceed a creation with new( ), now, this syntax doesn’t always works by lack of “default constructors”.

QUESTION 2: Is there a way to create a temporary “UObject child class” inside a function than not the object constructor? How?

By what I’ve seen, while is not certain that I’ll be allowed to create temporary objects to manipulate on my functions, C++ offers the Pointers and References that are freely “creatable” and can be simply and fast initialized with “nullptr” (Thanks to Epic by manage the <sizeof>, allocation, ZeroMemory and all boring things). One solution, should be

return inlineeverything(parameter)->method(parameter); 

But, program this way is crazy specially on complex methods, and this make me think…

QUESTION 3: Was the UScript keyword local always internally an instruction to build function’s internal pointers or a conditional pointer/reference depending on each case?

Well, by now it’s all I can remember, thank you for your time.

Yes, it has exactly the same purpose.

Unlike in UnrealScript, not everything in C++ needs to be an UObject or an AActor. You can create your own plain old C++ classes and structs and, if needed, instantiate them on the heap, i.e. FMyCoolClass().DoSomething();

If your type has to be (or already is) an UObject then you have to create it using the facilities for creating UObjects. You can’t easily create them on the heap, because they have a constructor that takes the PCIP parameter, and they are also managed by the garbage collector. Check our online documentation for details on how to create UObjects and how to spawn AActors.

UStructs on the other hand will be fine. For example, you can do FDateTime().ToString(); or FVector().DistSquared();

The ‘local’ keyword was used to declare local variables, if I remember correctly.

You can now declare local variables C++ style, for example:

void UMyObject::DoSomething()
    FVector LocalVectorVariable;

Thank youuuuu for UE4 C++ Tim Sweeney, Gerke, Marc Audy, and the Rest of Epic!



Thank you Max, I think that now I have enough to do some more tests. :smiley: