summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorTyge Løvset <[email protected]>2020-03-13 23:34:47 +0100
committerGitHub <[email protected]>2020-03-13 23:34:47 +0100
commit1ecafc3f6274bedf98a9c913d7a0b7759ff3c794 (patch)
tree1444a78646fb1e2efacecaccc204008710d18a25
parent849cf5d6adbf20ad7bd9fd069f52dbea9f0e3c24 (diff)
downloadSTC-modified-1ecafc3f6274bedf98a9c913d7a0b7759ff3c794.tar.gz
STC-modified-1ecafc3f6274bedf98a9c913d7a0b7759ff3c794.zip
Update EXAMPLE.md
-rw-r--r--EXAMPLE.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/EXAMPLE.md b/EXAMPLE.md
index 5936876d..dab05d01 100644
--- a/EXAMPLE.md
+++ b/EXAMPLE.md
@@ -8,7 +8,7 @@ To be able to use CMap (or one of the other unordered associative containers) wi
The difficulty with the hash function is that if your key type consists of several members, you will usually have the hash function calculate hash values for the individual members, and then somehow combine them into one hash value for the entire object. For good performance (i.e., few collisions) you should think carefully about how to combine the individual hash values to ensure you avoid getting the same output for different objects too often.
-A fairly good starting point for a hash function is one that uses bit shifting and bitwise XOR to combine the individual hash values. For example, assuming a key-type like this:
+A starting point for a hash function is one that combines the individual hash values in a good manner. For example, assuming a key-type like this:
```
struct Key
{