为什么当int64_t更改为int32_t时班级人数增加

在我的第一个示例中，我有两个使用 int64_t 的位域。当我编译并获取类的大小时，我得到 8。

class Test
{
    int64_t first : 40;
    int64_t second : 24;
};
int main()
{
    std::cout << sizeof(Test); // 8
}

但是当我将第二个 bitfeild 更改为int32_t类的大小加倍到 16 时：

class Test
{
    int64_t first : 40;
    int32_t second : 24;
};
int main()
{
    std::cout << sizeof(Test); // 16
}

这在 GCC 5.3.0 和 MSVC 2015 上都会发生。但是为什么？

在你的第一个例子中

int64_t first : 40;
int64_t second : 24;

first 和 second 都使用单个 64 位整数的 64 位。这会导致类的大小为单个 64 位整数。在第二个示例中，您有

int64_t first : 40;
int32_t second : 24;

这是存储在两个不同内存块中的两个单独的位字段。您使用 64 位整数中的 40 位，然后使用另一个 32 位整数中的 24 位。这意味着您至少需要 12 个字节（此示例使用 8 位字节）。您看到的额外 4 个字节很可能是填充以在 64 位边界上对齐类。

正如其他答案和评论所指出的那样，这是实现定义的行为，您可以/将在不同的实现上看到不同的结果。

C 标准的位字段规则不够精确，无法告诉程序员有关布局的任何有用信息，但仍然拒绝实现本来可能是有用的自由。

特别是，位域需要存储在指定类型的对象中，或有符号/无符号等效的对象中。在第一个示例中，第一个位域必须存储在int64_t或uint64_t对象中，第二个也是如此，但有足够的空间让他们适应相同的对象。在第二个示例中，第一个位域必须存储在int64_t或uint64_t，第二个在int32_t或uint32_t中。 uint64_t将有 24 位，即使将其他位字段添加到结构的末尾，这些位也会被"搁浅";该uint32_t有 8 位，目前未使用，但可用于另一个宽度小于 8 的int32_t或uint32_t位域添加到类型中。

恕我直言，该标准在给编译器自由与给程序员有用的信息/控制之间取得了最糟糕的平衡，但它就是这样。就我个人而言，我认为如果首选语法允许程序员根据普通对象精确地指定其布局，位域会更有用（例如，位域"foo"应以 3 位存储，从字段"foo_bar"的第 4 位（值为 16）开始），但我知道没有计划在标准中定义这样的事情。

补充其他人已经说过的话：

如果要检查它，可以使用编译器选项或外部程序来输出结构布局。

请考虑以下文件：

// test.cpp
#include <cstdint>
class Test_1 {
    int64_t first  : 40;
    int64_t second : 24;
};
class Test_2 {
    int64_t first  : 40;
    int32_t second : 24;
};
// Dummy instances to force Clang to output layout.
Test_1 t1;
Test_2 t2;

如果我们使用布局输出标志，例如Visual Studio的/d1reportSingleClassLayoutX（其中X是类或结构名称的全部或部分）或Clang++的-Xclang -fdump-record-layouts（其中-Xclang告诉编译器将-fdump-record-layouts解释为Clang前端命令而不是GCC前端命令），我们可以将Test_1和Test_2的内存布局转储到标准输出。 [不幸的是，我不确定如何直接与GCC一起做到这一点。

如果我们这样做，编译器将输出以下布局：

Visual Studio：

cl /c /d1reportSingleClassLayoutTest test.cpp
// Output:
tst.cpp
class Test_1    size(8):
    +---
 0. | first (bitstart=0,nbits=40)
 0. | second (bitstart=40,nbits=24)
    +---

class Test_2    size(16):
    +---
 0. | first (bitstart=0,nbits=40)
 8. | second (bitstart=0,nbits=24)
    | <alignment member> (size=4)
    +---

铛：

clang++ -c -std=c++11 -Xclang -fdump-record-layouts test.cpp
// Output:
*** Dumping AST Record Layout
   0 | class Test_1
   0 |   int64_t first
   5 |   int64_t second
     | [sizeof=8, dsize=8, align=8
     |  nvsize=8, nvalign=8]
*** Dumping IRgen Record Layout
Record: CXXRecordDecl 0x344dfa8 <source_file.cpp:3:1, line:6:1> line:3:7 referenced class Test_1 definition
|-CXXRecordDecl 0x344e0c0 <col:1, col:7> col:7 implicit class Test_1
|-FieldDecl 0x344e1a0 <line:4:2, col:19> col:10 first 'int64_t':'long'
| `-IntegerLiteral 0x344e170 <col:19> 'int' 40
|-FieldDecl 0x344e218 <line:5:2, col:19> col:10 second 'int64_t':'long'
| `-IntegerLiteral 0x344e1e8 <col:19> 'int' 24
|-CXXConstructorDecl 0x3490d88 <line:3:7> col:7 implicit used Test_1 'void (void) noexcept' inline
| `-CompoundStmt 0x34912b0 <col:7>
|-CXXConstructorDecl 0x3490ee8 <col:7> col:7 implicit constexpr Test_1 'void (const class Test_1 &)' inline noexcept-unevaluated 0x3490ee8
| `-ParmVarDecl 0x3491030 <col:7> col:7 'const class Test_1 &'
`-CXXConstructorDecl 0x34910c8 <col:7> col:7 implicit constexpr Test_1 'void (class Test_1 &&)' inline noexcept-unevaluated 0x34910c8
  `-ParmVarDecl 0x3491210 <col:7> col:7 'class Test_1 &&'
Layout: <CGRecordLayout
  LLVMType:%class.Test_1 = type { i64 }
  NonVirtualBaseLLVMType:%class.Test_1 = type { i64 }
  IsZeroInitializable:1
  BitFields:[
    <CGBitFieldInfo Offset:0 Size:40 IsSigned:1 StorageSize:64 StorageOffset:0>
    <CGBitFieldInfo Offset:40 Size:24 IsSigned:1 StorageSize:64 StorageOffset:0>
]>
*** Dumping AST Record Layout
   0 | class Test_2
   0 |   int64_t first
   5 |   int32_t second
     | [sizeof=8, dsize=8, align=8
     |  nvsize=8, nvalign=8]
*** Dumping IRgen Record Layout
Record: CXXRecordDecl 0x344e260 <source_file.cpp:8:1, line:11:1> line:8:7 referenced class Test_2 definition
|-CXXRecordDecl 0x344e370 <col:1, col:7> col:7 implicit class Test_2
|-FieldDecl 0x3490bd0 <line:9:2, col:19> col:10 first 'int64_t':'long'
| `-IntegerLiteral 0x344e400 <col:19> 'int' 40
|-FieldDecl 0x3490c70 <line:10:2, col:19> col:10 second 'int32_t':'int'
| `-IntegerLiteral 0x3490c40 <col:19> 'int' 24
|-CXXConstructorDecl 0x3491438 <line:8:7> col:7 implicit used Test_2 'void (void) noexcept' inline
| `-CompoundStmt 0x34918f8 <col:7>
|-CXXConstructorDecl 0x3491568 <col:7> col:7 implicit constexpr Test_2 'void (const class Test_2 &)' inline noexcept-unevaluated 0x3491568
| `-ParmVarDecl 0x34916b0 <col:7> col:7 'const class Test_2 &'
`-CXXConstructorDecl 0x3491748 <col:7> col:7 implicit constexpr Test_2 'void (class Test_2 &&)' inline noexcept-unevaluated 0x3491748
  `-ParmVarDecl 0x3491890 <col:7> col:7 'class Test_2 &&'
Layout: <CGRecordLayout
  LLVMType:%class.Test_2 = type { i64 }
  NonVirtualBaseLLVMType:%class.Test_2 = type { i64 }
  IsZeroInitializable:1
  BitFields:[
    <CGBitFieldInfo Offset:0 Size:40 IsSigned:1 StorageSize:64 StorageOffset:0>
    <CGBitFieldInfo Offset:40 Size:24 IsSigned:1 StorageSize:64 StorageOffset:0>
]>

请注意，我用于生成此输出的 Clang 版本（Rextester 使用的那个）似乎默认将两个位字段优化为单个变量，我不确定如何禁用此行为。

标准说：

§ 9.6 位字段

类中位字段的分配对象是实现定义的。位字段的对齐方式由实现定义。[注意：位域在某些计算机上跨分配单元，而不是在其他人身上。位字段在某些计算机上从右到左分配，在其他计算机上从左到右分配。— 尾注]

C++11 论文

所以布局取决于编译器实现、编译标志、目标架构等。刚刚检查了几个编译器，输出大多是8 8：

#include <stdint.h>
#include <iostream>
class Test32
{
    int64_t first : 40;
    int32_t second : 24;
};
class Test64
{
    int64_t first : 40;
    int64_t second : 24;
};
int main()
{
    std::cout << sizeof(Test32) << " " << sizeof(Test64);
}

相关内容

最新更新

热门标签：