But you do not have the fastest hashes like XXH3, City64, Murmur3 ?I started this library 2 weeks ago and just haven't coded those yet. I've just added Murmur3:
And the output is bad for hashmaps because it needs an integer not a string.No library will satisfy everyone. You can adapt the code for your needs. I tried to write everything as simply as possible.
It would be easier to use in one's own project, if it was procedural code without classes, and we only had to import a single unit, rather than twoYes, but if someone needs multiple algorithms in one program then procedural code would be worse for him/her.
Perhaps these Move(Msg^, Tmp2, 4); can be replaced with tmp2 := unaligned(PCardinal(Msg)^)You are right, thank you.
However this is the only library on the Internet in any programming language where all these CRC variants are lookup-table-based- so they are fast.I am not sure it is the only one with lookup table, but for sure the most common versions (e.g. crc32 or crc32c) are slow in comparison to most production code.
Good idea.
Even if not used directly, it is a good reference for odd hash algorithms source code in pascal. O:-)
There is a similar hash registration in mORMot 2.
You can either run directly the low-level hashing functions, or you have some high-level catalog.
https://github.com/synopse/mORMot2/blob/master/src/crypt/mormot.crypt.secure.pas#L946or in a one-liner
var hasher: ICryptHash; begin hasher := Hash('crc32c'); hasher.Update('some text'); writeln(hasher.Final); end;
writeln(Hash('crc32c').Full('some text'));
mormot.core.secure unit supports 'md5', 'sha1', 'sha256', 'sha384', 'sha512', 'sha3_256', 'sha3_512' and 32-bit non-cryptographic 'crc32', 'crc32c','xxhash32', 'adler32', 'fnv32' for ICryptHash, and there are ICryptSigner for salted digest like 'hmac-sha1', 'hmac-sha256', 'hmac-sha384', 'hmac-sha512', and 'sha3-224', 'sha3-256', 'sha3-384', 'sha3-512', 'sha3-s128', 'sha3-s256'.
And there are the same catalog system for encryption, randomness and also certificates and asymetric cryptography, using either native mORMot code, or OpenSSL.
BTW in THasher.Update I would not use TStream.Size.
Some TStream classes don't support it, e.g. if they are redirected streams from another streams.
This is how I did it in mORMot:
https://github.com/synopse/mORMot2/commit/48254f80662884d30b6f8254cb32ac9e2226a083
That is, just read and hash as much data until it ends.
Perhaps these Move(Msg^, Tmp2, 4); can be replaced with tmp2 := unaligned(PCardinal(Msg)^)
I quickly scanned through some of the units and found that some of them have "Dialogs" in "uses" (e.g.BKDRHash, rshash, xxHash32, plus some more). Is this really needed? If not this would add an unnecessary dependence on LCL.No, it can be safely removed. It's just some residue I forgot to remove.
No library will satisfy everyone. You can adapt the code for your needs. I tried to write everything as simply as possible.
Perhaps these Move(Msg^, Tmp2, 4); can be replaced with tmp2 := unaligned(PCardinal(Msg)^)You are right, thank you.
But you need to write unaligned(..) Otherwise it might crash on some platforms