Download

How come Arrays are indexed with int32 instead of uint32?

Title is self-explanatory :stuck_out_tongue: Is there a reason that Arrays use int32 instead of uint32? I get a lot of signed / unsigned mismatch errors at times because of it and have to case to uint32 when calling functions on arrays. I just figured that uint32 would make more sense since you can never really have a negative element in an array… or can you through some kind of magic?

Perhaps for consistency with access from blueprints, since uint32 isn’t exposed to blueprint?

There are a couple of other minor reasons I can think of for doing it. In C++ arrays and pointers are in some ways interchangeable and a negative pointer offset is completely valid, if a little strange. Also sometimes you want to do a loop backwards through an array, counting down to 0, and using an unsigned int for the counter can screw up the loop condition. The following would result in an infinite loop due to integer underflow:


for(uint32 Idx = Ar.Num() - 1; Idx >= 0; --Idx) {}

More generally, I think it’s probably good practice to use signed integers for just about everything. About the only time I ever choose to use unsigned is for bit flags/bitwise manipulation. Otherwise I just use a signed int for consistency, even when I know the value it will contain will never be negative.

The stl vector uses an unsigned int for indexing, but from what I can see from a quick search, that was due to legacy reasons and is generally considered regrettable.

Integer overflow errors are easier to check with signed integers as far as I know.

I’m pretty sure it’s because unsigned ints generally wrap below 0 ? so when you try and use -1 as an invalid index equates to bugs right since it wraps?

It’s not that ints are not exposed, reflection system simply not support them, as it has only one Integer type which was explain by epic to not make Int type over complex in editor (not only blueprint), so Int32 is best pick here. uint8 is also supported and as property type name hint it is included for single byte manipulation.

Thanks guys, I completely forgot about the Blueprint side of things… makes a lot of sense.