我想在运行时使用测试来确定字节序，以便我可以确定移位的行为，并注意到我的编译器有点奇怪的优化。这表明它将运行的机器的字节序在编译时是已知的。
这是我定时的两个例程。使用const的例程2大约快了33％。
/* routine 1 */
int big_endian = 1 << 1;
for (register int i = 0; i < 1000000000; ++i) {
int value = big_endian ? 5 << 2 : 5 >> 2;
value = ~value;
}
/* routine 2 */
const int big_endian = 1 << 1;
for (register int i = 0; i < 1000000000; ++i) {
int value = big_endian ? 5 << 2 : 5 >> 2;
value = ~value;
}
例程2的速度与使用在编译时可计算的常量表达式的速度相匹配。如果换班的行为取决于处理器，那怎么可能呢？
另外，在旁注中，为什么我们将数字以最少有效数字大字节序数结尾，以及以结尾的数字结尾有效数字小字节序数。
修改
评论中有些人声称按位移位与字节顺序无关。如果这是真的，那是否意味着像3这样的数字总是存储为00000011 (big endian)而永远不会存储为11000000 (little endian)?如果确实如此，实际上似乎有意义，则不会使用小端时，它会很奇怪，因为10000000 00000000 00000000 (128)向左移动00000000 00000001 00000000 (256)?会变为{{1}}提前谢谢。
答案 0 :(得分：6)
编译器始终将构建的目标作为指令知道，并且字节序特定于架构。
大多数情况下，目标是当前机器之一或更通用的机器，除非您进行交叉编译。
答案 1 :(得分：6)
编译器假定目标处理器具有字节序。大多数情况下这是显而易见的，例如x86总是小端的。对于可能是其中任何一种的体系结构，如果默认设置不适合您，通常会有编译器开关。例如，gcc / arm具有-mlittle-endian（默认）和-mbig-endian标志。