String hashing design

Question

I'm in the process of developing a game engine and I would like to refer to game objects and assets by an integer id rather than by their string name. This should avoid any string comparisons at runtime. As a result I'm trying to implement the string hashing approach that Jason Gregory describes in Game Engine Architecture.

I've got the actual hashing working, using FNV-1a in my case, but there are some parts of the design from the book that I don't understand.

static StringId sid_foo = internString("foo");
static StringId sid_bar = internString("bar");
...
[stringid.h]

typedef U32 StringId;
extern StringId internString(const char* str);

[stringid.cpp]

static HashTable<StringId, const char*> gStringIdTable;

StringId internString(const char* str)
{
    StringId sid = hashCrc32(str);
    HashTable<StringId, const char*>::iterator it
        = gStringIdTable.find(sid);
    
    if (it == gStringTable.end())
    {
        // This string has not yet been added to the
        // table. Add it, being sure to copy it in case
        // the original was dynamically allocated and
        // might later be freed.
        gStringTable[sid] = strdup(str);
    }
    return sid;
}

1. Presumably HashTable is a custom hash table implementation as no such class exists in C++? Is there any problem with my current setup of storing the hashed strings in a std::unordered_map<StringID, const char*>?
2. From my research, making the hash table static means that it is only accessible inside this translation unit. a) Why is it defined this way, and how would you then access the hash table in the rest of the game engine? b) Or do you call internString for every string and store the returned hash in a header #included in every file that needs access?
3. What is the purpose of making externString extern?

Thanks.

Answer 1

In the book, the subsection 5.4.3 you took the example from is about "ideas". It doesn't seem like the code snippet is meant to be great C++, just good enough to serve as an example that explains the concept.

Yes, you can substitute any hash map.

"how would you then access the hash table in the rest of the game engine?"

From the book, below the example:

When using string ids, the strings themselves are only kept around for human consumption. When you ship your game, you almost certainly won’t need the strings—the game itself should only ever use the ids.

In the book, the topic of that section is unique string identifiers for internal use. You will want to access the map for debugging only, and how you do so is up to you.

The book also mentions looking at FName as a working implementation of a similar concept.*

Strings that are presented to the player need to be handled differently - here you have to look into localization first, because that's where most of the constraints come from.

---

PS: As a bit of unsolicited advice, this introduces a level of complexity that is unnecessary for a home-built first game engine. Just make a class that looks like FName, only declare the parts you currently need (constructor and comparison), but implement it with std::string and operator== as a first draft. When you later need the additional performance you can then change the implementation to one that uses integer comparisons.