是否使用联合代替定义了良好的铸造？

问题描述

| 今天早上，我与一位同事讨论了用于检测字节序的“编码技巧”的正确性。 诀窍是：

bool is_big_endian()
{
  union
  {
    int i;
    char c[sizeof(int)];
  } foo;


  foo.i = 1;
  return (foo.c[0] == 1);
}

在我看来，this 1的这种用法是不正确的，因为设置联合的一个成员并读取另一个成员的定义不明确。但是我不得不承认，这只是一种感觉，我缺乏实际的证据来证明我的观点。 这个技巧正确吗？谁在这里？     

解决方法

您的代码不可移植。它可能在某些编译器上工作，也可能没有。 您尝试访问联合的不活动成员时，行为是不确定的，这是正确的（就像给出的代码一样） $ 9.5 / 1   在联合中，最多可以在任何时间激活一个数据成员，也就是说，可以随时在联合中存储最多一个数据成员的值。 因此，

foo.c[0] == 1

是不正确的，因为ѭ3at此时未处于活动状态。如果您认为我错了，请随时纠正我。     ,不要这样做，最好使用如下所示的内容：

#include <arpa/inet.h>
//#include <winsock2.h> // <-- for Windows use this instead

#include <stdint.h>

bool is_big_endian() {
  uint32_t i = 1;
  return i == htonl(i);
}

说明：   htonl函数将u_long从主机转换为TCP / IP网络字节顺序（big-endian）。 参考文献： http://linux.die.net/man/3/htonl http://msdn.microsoft.com/de-de/library/ms738556%28v=vs.85%29.aspx     ,您是正确的，该代码没有明确定义的行为。这是可移植的方法：

#include <cstring>

bool is_big_endian()
{
    static unsigned const i = 1u;
    char c[sizeof(unsigned)] = { };
    std::memcpy(c,&i,sizeof(c));
    return !c[0];
}

// or,alternatively

bool is_big_endian()
{
    static unsigned const i = 1u;
    return !*static_cast<char const*>(static_cast<void const*>(&i));
}

    ,该函数应命名为is_little_endian。我认为您可以使用这种联合技巧。或者也可以转换为char。     ,该代码具有未定义的行为，尽管某些（大多数？）编译器会 至少在有限的情况下定义它。 该标准的目的是将“ 6”用于 这个。但是，由于标准 不能真正定义行为；没有欲望在什么时候定义它 硬件将不支持它（例如，由于对齐问题）。和 很明显，你不能只在两个之间

reinterpret_cast

任意类型，并期望它能工作。 从实施质量的角度来看，我希望 如果

union

或the1 the

reinterpret_cast

在同一功能块中；

union

应该 只要编译器可以看到最终类型是

union

就可以工作 （尽管我不是在这种情况下使用过编译器）。