平台特定放置

除非包装编译选项或编译指示被使用，像下面（假设8位炭和16位短）平台特定放置

struct foo 
{ 
    short a ; 
    char b ; 
    short c ; 
} ;

代码将结束与，以据我所知，在我们的产品支持的所有平台（相当一部分）上的c之前有一个字节的对齐板。

我不记得看到的是没有把b和c之间的对齐填充任何平台，但试想，一个编译器可能只是在法律上把a和b之间的填充。（动机：我们在代码中引入了一些基础结构，以确保当前写入磁盘或涉及网络流的某些结构的二进制兼容性，并且在可能的情况下希望插入明确的填充以便其他开发人员意识到这些数据结构在封面下消耗的额外存储空间）。

有没有人知道一个平台谁是编译器没有把对齐填充，如果需要，立即之前将成为未对齐的成员？

来源

2012-09-07 Peeter Joot

有趣的问题。我很好奇你为什么以这种方式问你关于这个C危险区域的问题，你愿意分享你的动机吗？ –

如果某个平台将“short”和“char”对齐到4个字节会怎样？在未来的平台上可能有很好的理由，例如：http://gcc.gnu.org/wiki/Atomic/GCCMM/DataRaces – ninjalj

我强烈推荐阅读[编写可移植代码]（http：//www.hookatooka的.com/WPC /）。使用结构来序列化数据不是一个好主意。包装和endianess会让你每一次。 – jszakmeister

它不是我知道的任何地方，但MSVC（和gcc，我相信，兼容性）支持#pragma pack允许控制结构打包并允许错位访问。

基本上，C结构的字节布局的任何假设只是要求麻烦。这样做的代码也倾向于陷入对字词排序的假设陷阱，这是绝对是在普通平台之间不兼容。

来源

2012-09-07 17:29:34

'#pragma pack'就是我在'包装杂记'这个问题上的意思。当'#pragma pack'或等效（邪恶）编译器选项不被使用时，我对默认行为感兴趣。 –

我重申我的警告：如果您对结构布局做出假设，您将在未来面临可怕的可移植性错误。不要这样做。烹饪你的存储空间，不要泡菜。 –

平台特定放置

回答

相关问题