C++编译器能否重新排列结构体中的元素?

15

C++编译器(特别是g++)能否重新排列结构体的内部元素?

我遇到了一些奇怪的行为,我的一个结构体包含以下内容:

Struct SomeStruct{
   ...
   ...
   long someLong;
   long someLongArray[25];
   unsigned long someUnsignedLong;
   unsigned long someUnsignedLongArray[8];
   unsigned long int someUnsignedLongInt;
   ...
   ...
};

当我将这些输出到文件时,someUnsignedLongArraysomeLongArray的顺序似乎被颠倒了(即在someUnsignedLong之后出现了someLongArray[]中的元素,在someLong之后出现了someUnsignedLongArray[]中的元素)。这种情况可能吗?

谢谢。


更新: 按要求,我正在使用以下方式写出结构:

int fd = open(fspec,O_RDWR|O_CREAT|O_TRUNC,0666);
int writeRes =  write(fd,(char *)&someStruct,sizeof(SomeStruct));

为了完整起见,以下是完整的结构体:

struct SomeStruct{
byte someByte;
byte someByteArray[6];
char someChar;
char someCharArray[5];
char someCharArrayArray[3][5];
short someShort;
signed short someShortArray[2];
unsigned short someUnsignedShort;
unsigned short someUnsignedShortArray[8];
int someInt;
int someIntArray[3];
int someIntArrayArrayArrayArray[4][3][2][6];
int *pSomeInt;
unsigned int someUnsignedInt;
unsigned int someUnsignedIntArray[9];
long someLong;
long someLongArray[25];
unsigned long someUnsignedLong;
unsigned long someUnsignedLongArray[8];
unsigned long int someUnsignedLongInt;
long long someLongLong;
long long someLongLongArray[5];
bool someBool;
bool someBoolArray[3];
unsigned long long someUnsignedLongLong;
unsigned long long someUnsignedLongLongArray[5];
unsigned long long someUnsignedLongLongArrayArray[5][2];
unsigned long long int *pSomeUnsignedLongLongInt;
};

你如何将结构体写入文件? - tstenner
你确定你看到的是你认为看到的吗?也就是说,你是否已经在每个元素中编写了唯一的位模式,并可以将其追踪到文件?此外,你在结构体周围使用了什么#pragma pack(如果有的话)? - Peter M
也许他正在将结构体的字节而不是结构体的元素写入文件。 - isekaijin
你能替换掉 "..." 并编写一个展示问题的主函数吗?结构体中还有什么其他内容以及你如何将其写入文件都会产生影响。你是否将 SomeStruct* 强制转换为 char* 并写入了 sizeof(SomeStruct) 字节,或者采取了其他方法? - Steve Jessop
顺便提一下:你可以使用“offsetof”来检查字段的顺序,而无需将任何内容写入磁盘。 - Steve Jessop
你是在 x86 CPU 上运行这段代码吗?考虑到大小端,如果想要您的代码具有可移植性,最好逐个元素地编写结构体(使用适当的 hton() 宏)。 - Andreas Magnusson
2个回答

35

通常情况下,它无法重新排序元素。

一个例外是如果它们之间有访问修饰符:

struct Foo {    
  A a;
  B b;
  C c;
private:
  D d;
  E e;
  F f;
};

保证abc按照这个顺序存储,def也是有序的存储。但是对于abcdef的存储位置没有任何保证。

另外要注意的是,即使编译器不重新排序,它也可以插入尽可能多的填充。

以下是标准的相关部分:

第9.2.12节:

  

非静态数据成员在未声明访问说明符的(非联合)类中被分配,以便稍后的成员在类对象中具有更高的地址。隔有访问说明符分隔的非静态数据成员的分配顺序未指定(11.1)"


只是好奇,你有这方面的引用吗?我不是说你错了,但拥有一份引用会很有用。 - Doug T.
我认为只有POD类型的变量不能在访问控制块内重新排序。非POD类型的变量根本没有任何顺序要求。但既然你已经在查找Doug T的资料了,而我的副本又在楼上,我就让你去查一下吧;-) - Steve Jessop
哎呀,我猜我最好去查一下... ;) 9.2.12说:“未经访问说明符声明的(非联合)类的非静态数据成员被分配,以便稍后的成员在类对象内具有更高的地址。由访问说明符分隔的非静态数据成员的分配顺序是未指定的(11.1)。” @onebyone:有趣的是,它似乎没有提到 POD vs non-POD 的任何内容。如果你确定了,我就让你去查一下。 ;) - jalf
我不确定 - 出于某种原因,我认为有关订单的内容在POD部分中,但显然不是这样。 - Steve Jessop

8

当我说“反向”时,我指的是一些无符号长整型数组[]中的元素紧随在一些长整型变量someLong之后。我会澄清这个问题。 - Lehane
这不是因为不允许,而是因为这很复杂且会破坏许多事情。GCC 能够做到这一点,对此仍在进行研究。参见 有没有 GCC 关键字可以允许结构重排? - phuclv

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接