The C code of MurmurHash3有这部分:
uint64_t k1 = 0;
uint64_t k2 = 0;
switch(len & 15)
{
case 15: k2 ^= ((uint64_t)tail[14]) << 48;
case 14: k2 ^= ((uint64_t)tail[13]) << 40;
case 13: k2 ^= ((uint64_t)tail[12]) << 32;
case 12: k2 ^= ((uint64_t)tail[11]) << 24;
case 11: k2 ^= ((uint64_t)tail[10]) << 16;
case 10: k2 ^= ((uint64_t)tail[ 9]) << 8;
case 9: k2 ^= ((uint64_t)tail[ 8]) << 0;
(尾巴的类型是uint8_t *)
据我所知,它与OR操作没有什么不同.在这里使用XOR有什么不同?是优化吗?如果是,它是什么类型的?或者我错过了这两个操作符的行为差异?
我已经知道XOR和OR之间的区别.但在这种情况下,由于值在开始时归零,而xored值不重叠,因此行为不应与OR完全不同.所以我问为什么作者选择了这个而不是OR(它的意图比XOR imho更好).
最佳答案 是的,在这种情况下,它们完全相同.此外,由于它们是等效的,因此编译器可以单独使用它进行优化.编译时,您无法保证它实际上是或xor xor.实际上,在更一般的层面上,只要编译器生成可观察行为相同的代码,就不能保证它们是任何一个.
使用xor的一个合理的理由是,这是有问题的程序员首先想到的,或者代码最初是以一种重要的方式编写的,但后来被改为一个无关紧要的版本.但由于它们在这种情况下是等价的,因此很难知道.