blocks|key|928043|text|我可以假设，在一个32位的系统中，字符的填充将使它总共是4个字节，32位的指针是4，所以总的大小是8，对吧？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|928044|？|blockquote|928045|928046|928047|假设这一点是不安全的，但情况往往是这样的，是的。对于x86，字段通常是32位对齐的。这样做的原因是以内存使用为代价来提高系统的性能(参见here)。|offset|length|928048|因为指针是8个字节，所以我可以说这个结构在x64中是12个字节吗？|928049|或者你认为它应该是什么？|928050|928051|928052|同样，对于x64，字段通常是64位/8字节对齐的，因此sizeof(bar)应为16。|style|CODE|928053|然而，正如安德斯指出的那样，一旦你开始通过/Zp、pack+directive或任何你的编译器支持的东西进行对齐，所有这些都会被抛在脑后。|928054|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Data_structure_alignment|1|http://msdn.microsoft.com/en-us/library/xh3e3fd0(VS.80).aspx)|2|http://msdn.microsoft.com/en-us/library/2e70t5y1(VS.80).aspx)^0|0|0|0|0|1W|4|0|0|0|0|0|0|R|B|0|L|3|1|P|E|2|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|19|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1C|8|@]|9|@$I|1D|J|1E|1|1F]]|A|$]]|$1|K|3|L|5|6|7|1G|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1H|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1K|8|@$I|1L|J|1M|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1N|8|@]|9|@$I|1O|J|1P|1|1Q]|$I|1R|J|1S|1|1T]]|A|$]]|$1|W|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]|14|$5|Z|10|11|A|$12|15]]|16|$5|Z|10|11|A|$12|17]]]]

<blockquote>
 I can assume that on a 32 bit system,
 that padding for char will make it 4
 bytes total, and a pointer in 32 bit
 is 4, so the total size will be 8
 right?
</blockquote>

It's not safe to assume that, but that will often be the case, yes. For x86, fields are usually 32-bit aligned. The reason for this is to increase the system's performance at the cost of memory usage (see <a href="http://en.wikipedia.org/wiki/Data_structure_alignment" rel="nofollow noreferrer">here</a>).

<blockquote>
 Would I be right to say that the
 struct will be 12 bytes in a x64 arch,
 because pointers are 8 bytes? Or what
 do you think it should be?
</blockquote>

Similarly, for x64, fields are usually 64-bit/8-byte aligned, so <code>sizeof(bar)</code> would be 16.

As Anders points out, however, all this goes flying out the window once you start playing with alignment via <a href="http://msdn.microsoft.com/en-us/library/xh3e3fd0(VS.80).aspx" rel="nofollow noreferrer">/Zp</a>, the <a href="http://msdn.microsoft.com/en-us/library/2e70t5y1(VS.80).aspx" rel="nofollow noreferrer">pack directive</a>, or whatever else your compiler supports.

blocks|key|1674160|text|这是一个编译器开关，你不能假设任何东西。如果你认为你可能会有麻烦。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1674161|例如，在Visual+Studio中，您可以决定直接在字节边界上使用杂注pack(1)。|1674162|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Its a compiler switch, you can't assume anything. If you assume you may get into trouble.

For instance in Visual Studio you can decide using pragma pack(1) that you want it directly on the byte boundary.

blocks|key|925974|text|你不能在一般情况下假设任何事情。每个平台都有自己的填充规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|925975|也就是说，任何使用“自然”对齐的架构，其中操作数被填充到它们自己的大小(必要且足够避免跨越自然对齐的页面、缓存线等)，将使bar的指针大小加倍。|offset|length|style|CODE|925976|因此，给定自然对齐规则，32位上为8字节，64位上为16字节。|925977|entityMap^0|0|1P|3|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

You can't assume anything in general. Every platform decides its own padding rules.

That said, any architecture that uses "natural" alignment, where operands are padded to their own size (necessary and sufficient to avoid straddling naturally-aligned pages, cachelines, etc), will make <code>bar</code> twice the pointer size.

So, given natural alignment rules and nothing more, 8 bytes on 32-bit, 16 bytes on 64-bit.

blocks|key|4226489|text|$9.2/12-|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4226490|分配未使用中间访问说明符声明的(非联合)类的|4226491|非静态数据成员，以便后面的成员在类对象中具有更高的地址。由访问说明符分隔的非静态数据成员的分配顺序未指定(11.1)。实现对齐需求可能会导致两个相邻的成员不能紧接着彼此分配；管理虚拟函数(10.3)和虚拟基类(10.1)的空间需求也是如此。|blockquote|4226492|4226493|4226494|因此，正如您已经提到的，它是高度特定于实现的。|4226495|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

$9.2/12-

<blockquote>
 Nonstatic data members of a
 (non-union) class declared without an
 intervening access-specifier are
 allocated so that later members have
 higher addresses within a class
 object. The order of allocation of
 nonstatic data members separated by an
 access-specifier is unspecified
 (11.1). Implementation alignment
 requirements might cause two adjacent
 members not to be allocated
 immediately after each other; so might
 requirements for space for managing
 virtual functions (10.3) and virtual
 base classes (10.1).
</blockquote>

So, it is highly implementation specific as you already mentioned.

blocks|key|2817655|text|不完全是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2817656|填充取决于下一个构件的对齐要求。内置数据类型的自然对齐方式是它们的大小。|2817657|由于char成员的对齐要求为1(假设char为1字节)，因此在char成员之前没有填充。|2817658|例如，如果一个char+(同样假设它是一个字节)后面跟着一个short，比如说，它是2个字节，那么可能有多达1个字节的填充，因为short必须是2字节对齐的。如果字符后面跟着大小为8的双精度，则最多可能有7个字节的填充，因为双精度是8字节对齐的。另一方面，如果短整型后跟双精度型，则最多可以有6个字节的填充。|2817659|并且结构的尺寸是具有最大对准要求的构件的对准的倍数，因此可能存在尾部填充。例如，在下面的结构中，|2817660|struct+baz+{
++++double+d;
++++char+c;
};|code-block|syntax|javascript|2817661|对齐要求最大的成员是d，它的对齐要求是8，这给出了sizeof(baz)+==+2*+alignof(double)。在成员c之后有7个字节的尾部填充。|2817662|gcc和其他现代编译器支持__alignof()运算符。boost中也有一个便携版本。|2817663|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

Not quite.

Padding depends on the alignment requirement of the next member. The natural alignment of built-in data types is their size. 

There is no padding before char members since their alignment requirement is 1 (assuming char is 1 byte).

For example, if a char (again assume it is one byte) is followed by a short, which, say, is 2 bytes, there may be up to 1 byte of padding because a short must be 2-byte aligned. If a char is followed by double of the size of 8, there may be up to 7 bytes of padding because a double is 8-byte aligned. On the other hand, if a short is followed by a double, the may be up to 6 bytes of padding.

And the size of a structure is a multiple of the alignment of a member with the largest alignment requirement, so there may be tail padding. In the following structure, for instance,

<pre><code>struct baz {
 double d;
 char c;
};
</code></pre>

the member with the largest alignment requirement is d, it's alignment requirement is 8, Which gives sizeof(baz) == 2 * alignof(double). There is 7 bytes of tail padding after member c. 

gcc and other modern compilers support __alignof() operator. There is also a portable version in boost.

blocks|key|1674290|text|正如其他人所提到的，这种行为不能在平台之间依赖。但是，如果您仍然需要这样做，那么您可以使用BOOST_STATIC_ASSERT()来确保如果违反了假设，那么您可以在编译时发现，例如|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1674291|#include+<boost/static_assert.hpp>
#if+ARCH==x86+++++++++++++++++++++++++++++//+or+whatever+the+platform+specific+#define+is
++BOOST_STATIC_ASSERT(sizeof(bar)==8);
#elif+ARCH==x64
++BOOST_STATIC_ASSERT(sizeof(bar)==16);
#else+...|code-block|syntax|javascript|1674292|如果alignof()可用，您还可以使用它来测试您的假设。|1674293|entityMap^0|19|L|0|0|2|9|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

As others have mentioned, the behaviour can't be relied upon between platforms. However, if you still need to do this, then one thing you can use is <code>BOOST_STATIC_ASSERT()</code> to ensure that if the assumptions are violated then you find out at compile time, eg

<pre><code>#include &lt;boost/static_assert.hpp&gt;
#if ARCH==x86 // or whatever the platform specific #define is
 BOOST_STATIC_ASSERT(sizeof(bar)==8);
#elif ARCH==x64
 BOOST_STATIC_ASSERT(sizeof(bar)==16);
#else ...
</code></pre>

If <code>alignof()</code> is available you could also use that to test your assumption.

I got a structure like this:

<pre><code>struct bar {
 char x;
 char *y;
};
</code></pre>

I can assume that on a 32 bit system, that padding for char will make it 4 bytes total, and a pointer in 32 bit is 4, so the total size will be 8 right?

I know it's all implementation specific, but I think if it's within 1-4, it should be padded to 4, within 5-8 to 8 and 9-16 within 16, is this right? it seems to work.

Would I be right to say that the struct will be 12 bytes in a x64 arch, because pointers are 8 bytes? Or what do you think it should be?

Structures in C

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我得到了一个这样的结构：struct bar {    char x;    char *y;};我可以假设在32位系统上，字符的填充将使它总共4个字节，32位的指针是4，所以总大小是8，对吗？我知道这都是特定于实现的，但我认为如果它在1-4范围内，它应该填充到4，在5-8到8和9-16范围内16，这是正确的吗？它似乎起作用了。因为指针是8个字节，所以我可以说这个结构在x64中是12个字节吗？或者

问C语言中的结构
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C语言中的结构EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C语言中的结构
EN