Is there a static array similar to std::array or boost::array? @rcl said there might be way of using TArray with a static allocator!?
Hi,
We don’t have anything like std::array, which is simply a wrapper around a standard C array and thus has no concept of a variable number of container elements. If that’s what you want, please use a standard C array. 
If you want a container with a variable number of elements, but taking up a compile-time amount of space with no heap allocation, we do have a TFixedAllocator:
TArray<T, TFixedAllocator<256>> Array;
Here, the memory for the elements is inside the Array object itself. If you try to place more than 256 objects in the container, it will assert.
Steve
1 Like
Are there any reasons against adding a e.g. TStaticArray? Personally I can not imagine, why someone would want to use C arrays, when it’s very well understood, that sizeof checks or pointer access are very easy to get wrong.
Why is that “well understood”? That is a standard language feature.
What is your use case for TStaticArray over a TArray with fixed allocator? In general, arrays with a variable number of elements are more useful than those with a compile-time number of elements.
There is next to no overhead compared to a regular array, because the fixed allocator guarantees no runtime allocation and that the memory space for the elements are within the array object itself. I would be interested to hear if the overhead of a couple of extra ints in a fixed TArray has any real impact in your codebase.
The only real benefit I can possibly see for an array wrapper class is to be able to have a meaningful specialisation for an array of size 0, if it is something that can be defined by a macro or a compile-time expression.
Adding a TStaticArray is going to be unlikely because it’s something for people to learn and for us to maintain, along with extra code needed to support it in UnrealHeaderTool and the UProperty system - support which already exists for C arrays.
As for your point about sizeof, the ARRAY_COUNT macro should be used to determine array lengths rather than sizeof. This will cause a compile error if you accidentally use it on a pointer.
As I say, let me know if you have a compelling use case that isn’t covered by TArray<TFixedAllocator> or C arrays and then we can consider it, but if it’s just a syntactic concern, then I’m sorry to say it’s unlikely.
Steve
1 Like
+1 for TFixedAllocator.
I think it’s a bad practice to use C Arrays as they are very error prone (easy to calculate size wrong or call a wrong delete). if TArray with TFixedAllocator has no overhead over C arrays it’s perfect and should be always used instead of C arrays.
The only exception is that you cannot use UPROPERTY() mark up with TArray that’s got an non-default allocator.
Can we initialize the fixed size TArray? I’m using a static class as per Rama’s tutorial and I find it very useful. Currently the only way I can initialize any arrays is to use the standard c array stuff (which blows). I just tried putting the above fixed size TArray in my static class and initializing it like I would a standard C Array and no luck…
A TArray with a TFixedAllocator is still a TArray, so it still contains a variable number of elements and should be populated in the same way:
TArray<int32, TFixedAllocator<5>> MyArray;
MyArray.Add(0);
MyArray.Add(1);
MyArray.Add(2);
MyArray.Add(3);
MyArray.Add(4);
// MyArray.Add(5); // this will cause an assert as the array is full
Steve