acm*_*acm 5 c++ clang memcpy reinterpret-cast snappy
在snappy的内部,有一个有条件编译的部分选择取消引用reinterpret_cast'ed指针作为在已知支持此类操作的体系结构上可能未对齐的16,32和64位整数的读写的最佳实现(如86).其他架构的后备是使用基于memcpy的实现.
我的理解是reinterpret_cast实现展示了未定义的行为,并且clang的未定义行为清理程序确实标记了它.
令我困惑的是:为什么不使用基于memcpy的实现呢？我希望除了最破碎的编译器之外的所有编译器都使用内在函数来实现这些memcpy调用,因为在编译时已知大小.实际上,我希望在任何现代工具链上都可以使用相同的codegen.
然而,我也认识到,snappy是由知道它们是什么的人写的.所以这让我想知道使用reinterpret_cast机制是否还有一些优势,这种机制超过了它的未定义行为.不希望性能依赖于编译器的实现质量？我没有考虑过的其他事情？
如果不知道最初编写该代码的程序员，我怀疑您能否得到真正权威的答案。
这是我的最佳猜测：作者不想依赖可能的memcpy优化（规范绝不能保证这一点，即使它是由许多编译器实现的）。另一方面，reinterpret_cast在几乎任何编译器上编写 a 都非常非常有可能产生作者所期望的未对齐访问指令。
虽然智能的现代编译器会优化memcpy，但较旧的编译器可能不会。一致的性能对于这个库来说非常关键，因此他们似乎牺牲了一些正确性（因为它reinterpret_cast似乎可能是 UB），以支持在更广泛的编译器中获得更一致的结果。