Do you know why TArray<> & works differently than TArray <> in blueprints

Hi, I wanted to create a function in CPP that I could use in my blueprints but I stumbled on a rather strange behaviour.

I wanted to have a function that takes a TArray as an input and as an output so I did this :


(If you ask why I took the reference of the original array just to return another it is because at first I wanted to modify the original array but I had the weird behaviour, the screen was took in middle of my tests to fix it)

But I don’t know why, when I tried to use the node it was like this
image
There was no input and I don’t know why 2 outputs

So I tried some things but it is when I removed the “&” of the input TArray<> that I finally got the node that I wanted with 1 input 1 output.

I know that in a C++ function the “&” takes the reference to the original element and not a copy, is it linked to this behaviour ?

My problem is fixed now but if someone knows why it was a problem in the first place I would like to know.
Thanks

Hi ThaGureatestBoi,

Try defining it this way:

	UFUNCTION(BlueprintCallable)
	bool testPassAndReturnReferences(const TArray<AActor*>& inActors,TArray<AActor*>& outActors);

That gives you:

image

Doing it this way rather than return a new array avoids having to create copies of it…

1 Like

Thanks for your response, I will change my implementation.

As I understand depending on how we define our function parameters UE decides if it is considered an input or an output ?

1 Like

Yes that’s correct - if it’s a “const” it has to be an input.

1 Like

There is also a third option, which I think more closely matches your intended function:

	UFUNCTION(BlueprintCallable)
		static void WorkWithArray(UPARAM(Ref) TArray<AActor*>& Actors);

image

This macro tells Unreal to treat your array reference parameter as an input and lets you modify the input array in-place instead of returning a copy.

You would use this when you’re making changes to Arrays which can be quite large (think hundreds or thousands of entries). It’s generally safer and easier to reason about Arrays when you return copies, as RecourseDesign showed.

2 Likes

Thank you both for your responses, I have a better understanding of how UE interprets C++.