I'm confused that there are several hash string functions:
file: ..\Code\CryEngine\CryCommon\CryString\StringUtils.h My purpose is just convert string to int so that I can improve performance. But what is the different between CalculateHash & HashString?
Of course the hash string is guaranteed to be consistent through every machines under any circumstances, right?

Use official CE Docs online, the page is called crystring, here is the link for you:
http://docs.cryengine.com/display/SDKDOC4/CryString

Thanks for the good tips So I see that we should use this macro CONST_TEMP_STRING But don't you think using Hash string better than using map< string, int > like in the example above?

The code you posted that is from the documentation for CryString demonstrates how to get an iterator to a key/value pair from a map of <string, int> pairs. This does not turn your string into an int.

The hashing functions use known algorithms to "parse" a string and produce a fixed size output. In the examples you gave the output would be a 32bit (unsigned) integer. This means that collisions can occur if your string is too long. Technically, depending on the algorithm used it doesn't necessarily collide when the possibilities of the string exceed the 32 bit integer limit (4294967295).

Even with a perfect algorithm, you are guaranteed to be at risk of collisions when you hash a string (a-z only) longer than 7 characters, since with 7 characters there is a possible 8031810176 different combinations. you may want to check a wiki describing hash collisions in more detail. Mostly, it shouldn't be a problem, since most strings (I assume) will be readable English to some degree and minor variations will produce very different hashes.

Some has functions will be faster than others, with more or less features. (Unicode support for ex.).

I've been using a CHashedString whenever I need something to represent a hashed string and so far it's worked everywhere I've needed it. Just construct one from a string or char* and off you go. Some older parts of my code which were basically lifted from GameSDK do have calls to CryStringUtils::HashString and use CryHash - though I expect to deprecate most of that over time.

The hashing functions use known algorithms to "parse" a string and produce a fixed size output. In the examples you gave the output would be a 32bit (unsigned) integer. This means that collisions can occur if your string is too long. Technically, depending on the algorithm used it doesn't necessarily collide when the possibilities of the string exceed the 32 bit integer limit (4294967295).

Even with a perfect algorithm, you are guaranteed to be at risk of collisions when you hash a string (a-z only) longer than 7 characters, since with 7 characters there is a possible 8031810176 different combinations. you may want to check a wiki describing hash collisions in more detail. Mostly, it shouldn't be a problem, since most strings (I assume) will be readable English to some degree and minor variations will produce very different hashes.

My code is like this: So in theory, I should recognize hash collisions at the time I write the code (the #define one), the only thing I'm afraid is: on some strange console machine, the hash string generated at run time won't match what I define at compiled time.

Some has functions will be faster than others, with more or less features. (Unicode support for ex.).

But base on the comment of the 2 functions:
CalculateHash - Calculates a hash value for a given string.
HashString - This function is Unicode agnostic and locale agnostic.
I don't know which one is better, (look like HashString won't care about Unicode & locale. But what's about CalculateHash)

I've been using a CHashedString whenever I need something to represent a hashed string and so far it's worked everywhere I've needed it. Just construct one from a string or char* and off you go.

Thank ivanhawkes, CHashedString seems interesting, I'll consider using it in complicated case.

Some older parts of my code which were basically lifted from GameSDK do have calls to CryStringUtils::HashString and use CryHash - though I expect to deprecate most of that over time.

Why do you expect that? Is the code of CryStringUtils::HashString bad?

Some older parts of my code which were basically lifted from GameSDK do have calls to CryStringUtils::HashString and use CryHash - though I expect to deprecate most of that over time.

Why do you expect that? Is the code of CryStringUtils::HashString bad?

The code is probably fine but I prefer to unify my usage of code, and that means replacing code within my own project (or snipped from GameSDK) with new alternatives in the main code base when they become available. There really shouldn't be three different ways to calculate a string hash, it creates confusing and questions about compatibility and violates the DRY principle.

For your use case i would recommend CalculateHash.
Its a standard Crc32 implementation and should produce the same results as other crc32 hashes. I am using it as well for a similar purpose.
If you are on ce 5.4 you can also use Crc32::Compute_CompileTime to generate hashes at compile time instead of predefining them.

Thank sunnlok, that's information is really helpful