Class References in Functions, bug or feature?

I setup a function to handle moving a UObject from one array to another. I ran into some issues with the reference to the instances of the classes. In my mind, the two following functions should have the same behaviour, but in practice they do not. Have I been away from pointers for too long, or is this a bug?

In the second example, how are you checking the content of the arrays once they are not in scope?

Verifying the array move happened takes place outside these functions.

Maybe I do not see the big picture here, but the local arrays go out of scope after the function executes. At the moment function 2 (alt) does nothing.

The local arrays should be pointers to the memory space of the input array. Modifying them should modify the array in the pointer memory space. The arrays going out of scope is intended. My point is that in C++ these functions would have identical results, and that I was using local references to keep the blueprints easily readable.

In c++:

void SetArrayInDirect(UObject *MyObject, Array<UObject> *Array1, Array<UObject> *Array2) {

UObject *LocalObject = &MyObject;
Array<UObjects> *LocalArray1 = &Array1;
Array<UObjects> *LocalArray1 = &Array2;

**Doing Logic on the local variables will result in the logic being done on the pointers to the actual stored variables**

void SetArrayDirect(UObject *MyObject, Array<UObject> *Array1, Array<UObject> *Array2) {

**Doing Logic on the function arguments will result in the logic being done on the pointers to the actual stored variables**

This is not the case in the blueprint solution.

I believe it’s because you copy the array.

Have a look at this:


Epic set up traps in Blueprints for the folk versed in c++.

Yea I guess that makes sense, I should have tried that. (Last time I tried it, I was using variables that were pass by value :frowning: ) I will try it later and see if the functionality is correct. Thanks.