为什么将一个枚举变体设为“f64”会增加此枚举的大小？

Question

我创建了三个几乎相同的枚举：

#[derive(Clone, Debug)]
pub enum Smoller {
    Int(u8),
    Four([u8; 4]),
    Eight([u8; 8]),
    Twelve([u8; 12]),
    Sixteen([u8; 16]),
}

#[derive(Clone, Debug)]
pub enum Smol {
    Float(f32),
    Four([u8; 4]),
    Eight([u8; 8]),
    Twelve([u8; 12]),
    Sixteen([u8; 16]),
}

#[derive(Clone, Debug)]
pub enum Big {
    Float(f64),
    Four([u8; 4]),
    Eight([u8; 8]),
    Twelve([u8; 12]),
    Sixteen([u8; 16]),
}

pub fn main() {
    println!("Smoller: {}", std::mem::size_of::<Smoller>()); // => Smoller: 17
    println!("Smol: {}", std::mem::size_of::<Smol>()); // => Smol: 20
    println!("Big: {}", std::mem::size_of::<Big>()); // => Big: 24
}

鉴于我对计算机和内存的理解，我期望它们的大小应该相同。最大的变体是大小为 16 的 [u8; 16]。因此，虽然这些枚举的第一个变体的大小确实不同，但它们的最大变体大小相同，并且变体总数相同。

我知道 Rust 可以做一些优化来确认某些类型何时存在间隙（例如，指针可能会崩溃，因为我们知道它们将无效并且为 0），但这实际上恰恰相反。我想如果我手动构建这个枚举，我可以将它放入 17 个字节中（区分只需要一个字节），所以 20 个字节和 24 个字节都让我感到困惑。

我怀疑这可能与对齐有关，但我不知道为什么，也不知道为什么有必要这样做。

谁能解释一下？

谢谢！

Answer 1

大小必须至少为 17 字节，因为它的最大变体是 16 字节大，并且它需要一个额外的字节用于判别式（编译器在某些情况下可以很聪明，并将判别式放在变体的未使用位中，但这里不能这样做）。

另外，Big 的大小必须是 align f64 的 8 个字节的倍数。 8比17大的倍数是24。 同样，Smol 不能只有 17 个字节，因为它的大小必须是 4 个字节的倍数（f32 的大小）。 Smoller 只包含 u8 所以可以对齐到 1 个字节。

Answer 2

我认为是因为内部值的对齐要求。

u8 具有1 的对齐方式，所以一切都如您所愿，您得到的总大小为 17 个字节。

但是f32 的对齐方式是4（从技术上讲，它是依赖于拱门的，但这是最可能的值）。因此，即使判别式只有 1 个字节，您也会得到 Smol::Float 的这种布局：

[discriminant x 1] [padding x 3] [f32 x 4] = 8 bytes

然后对于Smol::Sixteen：

[discriminant x 1] [u8 x 16] [padding x 3] = 20 bytes

为什么这个填充真的很有必要？因为要求类型的大小必须是对齐的倍数，否则这种类型的数组会错位。

同样，f64 的对齐方式为 8，因此您得到的完整大小为 24，即适合所有枚举的 8 的最小倍数。

Answer 3

正如mcarton 提到的，这是内部字段对齐和对齐/大小规则的影响。

---

对齐

具体来说，内置类型的常见对齐方式是：

• 1：i8，u8。
• 2：i16，u16。
• 4：i32、u32、f32。
• 8：i64、u64、f64。

请注意，我说的是常见的，实际上对齐是由硬件决定的，在 32 位架构上，您可以合理地期望 f64 是 4 字节对齐的。此外，isize、usize 和指针的对齐方式会因 32 位和 64 位架构而异。

一般来说，为了便于使用，复合类型的对齐方式是其任何字段的最大对齐方式，递归方式。

对未对齐值的访问通常是特定于架构的；在某些架构上它会崩溃（SIGBUS）或返回错误数据，在某些架构上它会更慢（不久前的 x86/x64），而在其他架构上它可能会很好（在某些指令上是较新的 x64）。

---

大小和对齐方式

在 C 中，大小必须始终是对齐方式的倍数，因为数组的布局和迭代方式：

• 数组中的每个元素都必须正确对齐。
• 通过将指针递增sizeof(T) 字节来完成迭代。
• 因此大小必须是对齐方式的倍数。

Rust 继承了这种行为^1。

有趣的是，Swift 决定定义一个单独的内在函数 strideof 来表示数组中的步幅，这允许他们从 sizeof 的结果中删除任何尾部填充。它确实引起了一些混乱，因为人们期望 sizeof 表现得像 C，但可以更有效地压缩内存。

因此，在 Swift 中，您的枚举可以表示为：

• Smoller: [u8 x 16][discriminant] => sizeof 17 bytes，strideof 17 bytes，alignof 1 byte。
• Smol: [u8 x 16][discriminant] => sizeof 17 bytes，strideof 20 bytes，alignof 4 bytes。
• Big: [u8 x 16][discriminant] => sizeof 17 bytes，strideof 24 bytes，alignof 8 bytes。

这清楚地表明了 size 和 stride 之间的区别，它们在 C 和 Rust 中被混为一谈。

^1 我似乎记得一些关于可能切换到strideof 的讨论，正如我们所看到的那样没有实现，但找不到指向它们的链接。