Question

鉴于我需要解析的具有32位little-endian字段的二进制文件，我想编写正确编译的解析代码，而不依赖于执行该代码的机器的字节顺序。目前我使用

uint32_t fromLittleEndian(const char* data){
  return uint32_t(data[3]) << (CHAR_BIT*3) |
         uint32_t(data[2]) << (CHAR_BIT*2) |
         uint32_t(data[1]) << CHAR_BIT |
         data[0]; 
}

然而，这会产生不理想的组装。在我的机器上g++ -O3 -S生成：

_Z16fromLittleEndianPKc:
.LFB4:
    .cfi_startproc
    movsbl  3(%rdi), %eax
    sall    $24, %eax
    movl    %eax, %edx
    movsbl  2(%rdi), %eax
    sall    $16, %eax
    orl %edx, %eax
    movsbl  (%rdi), %edx
    orl %edx, %eax
    movsbl  1(%rdi), %edx
    sall    $8, %edx
    orl %edx, %eax
    ret
    .cfi_endproc

为什么会这样？我怎么能说服它在小端机器上编译时产生最佳代码：

_Z17fromLittleEndian2PKc:
.LFB5:
    .cfi_startproc
    movl    (%rdi), %eax
    ret
    .cfi_endproc

我通过编译得到了：

uint32_t fromLittleEndian2(const char* data){
    return *reinterpret_cast<const uint32_t*>(data);
}

因为我知道我的机器是小端的，所以我知道上面的程序集是最佳的，但是如果在big-endian机器上编译它会失败。它还违反了严格别名规则，因此如果内联它甚至可以在小端机器上产生UB。是否有一个有效的代码将被编译为最佳装配如果可能？

由于我希望我的函数内联很多，所以任何类型的运行时字节序检测都是不可能的。编写最佳C / C ++代码的唯一替代方法是使用编译时字节序检测，如果目标字节序不是小端，则使用template s或#define s回退到低效代码。然而，这似乎很难以便携式完成。

Answer 1

简短回答 - 使用htonl - 它将被优化为wazzoo

Answer 2

我所知道的各种平台库都是通过#defining宏来完成endian-swapping例程，基于#define BIG_ENDIAN的值。在源字节序与目标字节序匹配的情况下，您可以：

#ifdef LITTLE_ENDIAN
    #define fromLittleEndian(x) (x)
#else
    #define fromLittleEndian(x) _actuallySwapLittle((x))
#endif

例如：

http://man7.org/linux/man-pages/man3/endian.3.html

http://fxr.watson.org/fxr/source/sys/endian.h

c / c ++中endian的最佳和可移植转换

2 个答案: