When pass const TCHAR* to TMap::Find, implicitly FString temporary object is created.
Then literal string is copied to FString temporary object. this is slow.
I don’t want this. because it’s needless.
I think Hash value can be calculated with const TCAHR*(null-terminated).
But I can’t find way.
Please HELP!
Perhaps, the intention was to make TMap less error-prone for the people who don’t catch pointer-related at first glance.
I mean, this code will add 2 items into the set, even though it might be 1 expected:
TSet<TCHAR*> set;
TCHAR hello[] = "Hello";
set.Add("Hello");
set.Add(hello);
Most likely, this is done using TMap template specialization, so you can work around this by implementing a wrapper for such pointers:
struct StaticString
{
const TCHAR* m_ptr = nullptr;
// ...
};
Proof of concept example is here: godbolt.org
However, this will be correct only if you’re intentionally want to hash pointers rather than strings, so different pointers will be considered different even if they contain the same strings.
Just posted a way to compare and store pointers rather than their string content, and realized that I didn’t understand correctly your question. The pointer could not always be stored in the map.
Consider the case with STL’s unordered set that has no such fallback to the “owning” string object:
std::string exclamation()
{
return "!!1";
}
void FillSet(std::unordered_set<const char*>& set)
{
const char hello[] = "hello";
std::string world = "world";
set.insert(hello); // pointer to the local variable
set.insert(world.c_str()); // pointer to the local variable
set.insert(exclamation().c_str()); // pointer to the temporary
}
void Foo()
{
std::unordered_set<const char*> set;
FillSet(set);
// UB: all pointers that are stored in the 'set' are invalid
for (const char* s : set)
ObserveBugs(s);
}
This is quite an error-prone code, perhaps, Epic considered to make their TSet/TMap a bit more highlevel and error-proof.