Why doesn't UE utilize STL containers?

[Ovrloaded_Opr8r]

The issue with the reflection system is the best reason for staying with the custom containers imho, the second best reason is probably just the amount of work required to transition to more standard containers hasn’t been justifiable. Though, I do wish the custom containers where compatible with standard algorithms and such.

The claims that UE containers are more performant seem likely, given they are specialized, but I haven’t seen evidence of this.

Looking to the future of C++, there are plans to add reflection and metaprogramming to the language, lock3 has an experimental clang implementation, but I haven’t experimented with it. It may become worth using the standard language features when compilers officially support them someday (~5 yrs from now?), at which point, I think the arguments for not switching to standard containers mainly rests on performance and effort.

Just my 2c.

[jwatte]

@Roi_Danton

Until one comes with measurements, those performance claims are bull*

I would assume that the one proposing a change is the one with the burden of proof, no?

Anyway, it looks like, if your game is all TMaps, std:: is better. If your game is mostly TArray and TStrings, Unreal wins. (I’ve found that, at scale, “number of cache lines touched” is the best predictor of overall application performance, so smaller is almost always better from a global perspective. Microbenchmarks where there’s no pressure may perform differently.)

#include <string>
#include <map>
#include <vector>

void UBoomerBPFunctions::GetContainerSizes(int& outSizeVector, int& outSizeMap, int& outSizeString, int& outSizeTArray, int& outSizeTMap, int& outSizeFString)
{
    outSizeVector = sizeof(std::vector<std::string>);
    outSizeMap = sizeof(std::map<std::string, std::string>);
    outSizeString = sizeof(std::string);
    outSizeTArray = sizeof(TArray<FString>);
    outSizeTMap = sizeof(TMap<FString, FString>);
    outSizeFString = sizeof(FString);
}