管理 C++ 缓冲区中的对象，考虑对齐和内存布局假设

Question

我将对象存储在缓冲区中。 现在我知道我不能对对象的内存布局做出假设。

如果我知道对象的总体大小，是否可以创建指向该内存的指针并在其上调用函数？

例如说我有以下课程：

[int,int,int,int,char,padding*3bytes,unsigned short int*]

1） 如果我知道这个类的大小为 24 并且我知道它在内存中的起始地址 虽然假设内存布局不安全，但将其转换为指针并调用该对象上访问这些成员的函数是否可以接受？ （c++ 是否通过某种魔法知道成员的正确位置？）

2） 如果这不安全/没问题，除了使用构造函数获取所有参数并一次将每个参数从缓冲区中取出一个之外，还有其他方法吗？

编辑：更改标题以使其更适合我的要求。

Answer 1

您可以创建一个构造函数来获取所有成员并分配它们，然后使用placement new。

class Foo
{
    int a;int b;int c;int d;char e;unsigned short int*f;
public:
    Foo(int A,int B,int C,int D,char E,unsigned short int*F) : a(A), b(B), c(C), d(D), e(E), f(F) {}
};

...
char *buf  = new char[sizeof(Foo)];   //pre-allocated buffer
Foo *f = new (buf) Foo(a,b,c,d,e,f);

这样做的优点是即使 v-table 也能正确生成。 但请注意，如果您使用它进行序列化，则当您反序列化时，无符号短整型指针将不会指向任何有用的内容，除非您非常小心地使用某种方法将指针转换为偏移量，然后再返回。

this 指针上的各个方法是静态链接的，只是对函数的直接调用，this 是显式参数之前的第一个参数。

使用 this 指针的偏移量来引用成员变量。 如果一个对象的布局如下：

0: vtable
4: a
8: b
12: c
etc...

a 将通过取消引用 this + 4 字节 来访问。

Answer 2

基本上，您建议做的是读取一堆（希望不是随机的）字节，将它们转换为已知对象，然后调用该对象上的类方法。 它实际上可能有效，因为这些字节将最终出现在该类方法中的“this”指针中。 但是，您确实在冒险，因为事情并非编译后的代码所期望的那样。 与 Java 或 C# 不同，没有真正的“运行时”来捕获此类问题，因此最多您会得到核心转储，最糟糕的是您会得到损坏的内存。

听起来您想要 Java 序列化/反序列化的 C++ 版本。 可能有一个图书馆可以做到这一点。

Answer 3

非虚函数调用就像 C 函数一样直接链接。 对象（this）指针作为第一个参数传递。 调用该函数不需要了解对象布局。

Answer 4

听起来您没有将对象本身存储在缓冲区中，而是将组成它们的数据存储在缓冲区中。

如果此数据按照字段在您的类中定义的顺序存储在内存中（具有适合平台的适当填充）并且您的类型是POD，然后您可以将缓冲区中的数据memcpy到a指向您的类型的指针（或者可能对其进行强制转换，但请注意，存在一些特定于平台的陷阱，这些陷阱会强制转换为不同类型的指针）。

如果您的类不是 POD，则无法保证字段的内存布局，并且您不应该依赖任何观察到的顺序，因为它允许在每次重新编译时更改。

但是，您可以使用 POD 中的数据初始化非 POD。

至于非虚拟函数所在的地址：它们在编译时静态链接到代码段中的某个位置，该位置对于您的类型的每个实例都是相同的。 请注意，不涉及“运行时”。 当您编写如下代码时：

class Foo{
   int a;
   int b;

public:
   void DoSomething(int x);
};

void Foo::DoSomething(int x){a = x * 2; b = x + a;}

int main(){
    Foo f;
    f.DoSomething(42);
    return 0;
}

编译器会生成执行以下操作的代码：

1. function main：
   1. 在堆栈上为对象“f”分配 8 个字节
   2. 调用类“Foo”的默认初始化程序（在本例中不执行任何操作）
   3. 将参数值42压入堆栈
   4. 将指向对象“f”的指针压入堆栈
   5. 调用函数Foo_i_DoSomething@4（实际名称通常更复杂）
   6. 将返回值0加载到累加器寄存器
   7. 返回呼叫者
2. 函数 Foo_i_DoSomething@4 （位于代码段的其他位置）
   1. 从堆栈加载“x”值（由调用者推送）
   2. 乘以 2
   3. 从堆栈加载“this”指针（由调用者推送）
   4. 计算 Foo 对象中字段“a”的偏移量
   5. 将计算出的偏移量添加到第 3 步中加载的 this 指针
   6. 将第 2 步中计算出的乘积存储到第 5 步中计算出的偏移量
   7. 再次从堆栈加载“x”值
   8. 再次从堆栈加载“this”指针
   9. 再次计算 Foo 对象中字段“a”的偏移量
   10. 将计算出的偏移量添加到第 8 步中加载的 this 指针
   11. 加载存储在偏移处的“a”值，
   12. 将第 12 步加载的 int 值“a”添加到第 7 步加载的“x”值
   13. 再次从堆栈加载“this”指针
   14. 计算 Foo 对象中字段“b”的偏移量
   15. 将计算出的偏移量添加到第 14 步中加载的 this 指针
   16. 将第 13 步中计算出的总和存储到第 16 步中计算出的偏移量
   17. 返回呼叫者

换句话说，它或多或少与您编写的代码相同（具体信息，例如 DoSomething 函数的名称和传递 this 指针的方法）给编译器）：

class Foo{
    int a;
    int b;

    friend void Foo_DoSomething(Foo *f, int x);
};

void Foo_DoSomething(Foo *f, int x){
    f->a = x * 2;
    f->b = x + f->a;
}

int main(){
    Foo f;
    Foo_DoSomething(&f, 42);
    return 0;
}

Answer 5

1. 在这种情况下，一个POD类型的对象已经被创建了（无论你是否调用new。分配所需的存储已经足够了），并且你可以访问它的成员，包括调用该对象上的函数。 但这只有在您精确知道 T 所需的对齐方式、T 的大小（缓冲区可能不小于它）以及 T 所有成员的对齐方式的情况下才有效。即使对于 pod 类型，编译器也是如此如果需要的话，允许在成员之间放置填充字节。 对于非 POD 类型，如果您的类型没有虚函数或基类，没有用户定义的构造函数（当然），并且这也适用于基类及其所有非静态成员，那么您也可以有同样的运气。

2. 对于所有其他类型，一切都无效。 您必须首先使用 POD 读取值，然后使用该数据初始化非 POD 类型。

Answer 6

我将对象存储在缓冲区中。 ...如果我知道对象的总体大小，是否可以创建指向此内存的指针并在其上调用函数？

如果使用强制转换是可以接受的，那么这是可以接受的：

#include <iostream>

namespace {
    class A {
        int i;
        int j;
    public:
        int value()
        {
            return i + j;
        }
    };
}

int main()
{
    char buffer[] = { 1, 2 };
    std::cout << reinterpret_cast<A*>(buffer)->value() << '\n';
}

将对象强制转换为原始内存之类的东西然后再返回实际上是很常见的，尤其是在 C 世界中。 但是，如果您使用类层次结构，那么使用指向成员函数的指针会更有意义。

假设我有以下课程：...

如果我知道这个类的大小为 24 并且我知道它在内存中的起始地址...

这就是事情变得困难的地方。 对象的大小包括其数据成员（以及来自任何基类的任何数据成员）的大小加上任何填充加上任何函数指针或依赖于实现的信息，减去从某些大小优化（空基类优化）中保存的任何内容。 如果结果数为 0 字节，则要求该对象在内存中至少占用 1 个字节。 这些问题是语言问题和大多数 CPU 对内存访问的常见要求的结合。 尝试让事情正常工作可能是一件非常痛苦的事情。

如果您只是分配一个对象并在原始内存中进行转换，则可以忽略这些问题。 但是，如果您将对象的内部结构复制到某种缓冲区中，那么它们很快就会抬起头来。 上面的代码依赖于一些关于对齐的一般规则（即，我碰巧知道类 A 将具有与 int 相同的对齐限制，因此数组可以安全地转换为 A；但我不一定保证如果我将数组的一部分转换为 A，并将部分转换为具有其他数据成员的其他类，则效果相同）。

哦，当复制对象时，您需要确保正确处理指针。

您可能还对 Google 的 Protocol Buffers 或 Facebook 的 Thrift。

---

是的，这些问题很困难。 是的，有些编程语言将它们隐藏起来。 但是有很多东西正在获取扫到地毯下：

在 Sun 的 HotSpot JVM 中，对象存储与最近的 64 位边界对齐。 除此之外，每个对象在内存中都有一个 2 字标头。 JVM 的字大小通常是平台的本机指针大小。 （仅由 32 位 int 和 64 位 double 组成的对象（即 96 位数据）将需要）两个字用于对象头，一个字用于 int，两个字用于 double。 那是 5 个字：160 位。 由于对齐的原因，该对象将占用 192 位内存。

这是因为 Sun 依靠相对简单的策略来解决内存对齐问题（在假想的处理器上，可以允许 char 存在于任何内存位置，int 可以存在于任何可被 4 整除的位置，而 double 可能需要仅分配在可被 32 整除的内存位置上——但最严格的对齐要求也满足所有其他对齐要求，因此 Sun 根据最严格的位置来对齐所有内容。

另一种内存对齐策略可以回收部分空间。

Answer 7

1. 如果类不包含虚函数（因此类实例没有 vptr），并且如果您对类成员数据在内存中的布局方式做出正确假设，则执行您的操作建议可能有效（但可能不可移植）。
2. 是的，另一种方法（更惯用但不是更安全......您仍然需要知道该类如何布置其数据）是使用所谓的“放置运算符 new”和默认构造函数。

Answer 8

这取决于你所说的“安全”是什么意思。 每当您以这种方式将内存地址转换为点时，您都​​会绕过编译器提供的类型安全功能，并自行承担责任。 正如 Chris 所暗示的那样，如果您对内存布局或编译器实现细节做出了错误的假设，那么您将得到意外的结果和松散的可移植性。

由于您担心这种编程风格的“安全性”，因此可能值得您花时间研究可移植和类型安全的方法，例如预先存在的库，或者为此目的编写构造函数或赋值运算符。