Nested Containers & UBT Bug with Compiler Warnings

I’ve just discovered that it’s not possible to have nested containers, such as 2D TArrays<> for example (weird that I’ve never tried to use them before now).

While I’m okay with this, there is a bug with UBT in regards to them. If you create a 2D TArray of FVectors, and DON’T mark the variable as a UPROPERTY, the code will compile and execute without problems, but the FVectors will all read as zero even if they’re not. For example:

--- .h ---
TArray<TArray<FVector>> GridBuffer;

--- .cpp ---
FVector UMyClass::GetPosAtGrid(const int32 ColumnX, const int32 RowY)
	return GridBuffer[ColumnX][RowY];

Will compile and return zeroed vectors, any accesses and writes will appear to work fine though. If you mark it as a UPROPERTY, you get the warning in UBT. This is probably a bug and UBT shouldn’t allow this to compile, unless it’s being changed for the future?

A TArray of TArrays is perfectly valid C++ and it should work just fine except for as a property. The property system isn’t currently set up to handle nested containers, but that is a problem with the property system and nothing to do with the actual containers themselves.

Ahhh okay interesting. Good to know!

Have you tried wrapping second level TArray into UStruct? I’d expect that kind of thing to work.

Yeah I saw that on the Wiki but it felt a bit ‘hacky’, but I guess in reality it doesn’t make a difference. In the end I just used a 1D array and wrote a function to ‘fake’ it being 2D (pass in two indices, get one item back kind of thing). Probably faster to access this way anyway.

Wouldn’t call that hacky. TArray is not an UCLASS/USTRUCT, so when you nest them, property system won’t be able to pickup 2nd level TArray. So, wrapping things into UStruct seems like a fairly obvious choice.

Oh, and representing 2d array as 1d is a good idea. Array of Array of X (or vector of vector of X) only really makes when your rows can have different lengths. You could also add blueprint accessor to that, if you wanted.