在没有动态内存分配的情况下复制 C 中的任意类型

Question

问题：

我想我已经找到了一种方法，据我所知，它允许您编写完全与类型无关的代码，该代码在“堆栈”上复制任意类型的变量（在引号中，因为 C 标准确实实际上并不需要有一个堆栈，所以我真正的意思是它是在本地范围内与自动存储类一起复制的）。这里是：

/* Save/duplicate thingToCopy */
char copyPtr[sizeof(thingToCopy)];
memcpy(copyPtr, &thingToCopy, sizeof(thingToCopy));

/* modify the thingToCopy variable to do some work; do NOT do operations directly on the data in copyPtr, that's just a "storage bin". */

/* Restore old value of thingToCopy */
memcpy(&thingToCopy, copyPtr, sizeof(thingToCopy));

从我有限的测试来看，它可以工作并且接近我可以告诉它应该适用于所有符合标准的 C 实现，但以防万一我错过了什么，我想知道：

• 这是否完全符合 C 标准（我相信从 C89 一直到现代的东西都应该很好），如果不是，是否可以修复以及如何修复？
• 为了保持符合标准，此方法对自身施加了哪些使用限制？
  • 例如，据我了解，只要我从不直接使用 char-array 临时副本，就可以避免对齐问题 - 就像使用 memcpy 保存和加载的 bin 一样。但是我不能将这些地址传递给其他函数，期望指向我正在使用的类型的指针，而不会冒对齐问题的风险（显然在语法上我可以通过首先从char * 获取void * 来反常地做到这一点，甚至没有指定我正在使用的确切类型，但重点是我认为这样做会触发未定义的行为）。
• 是否有更简洁和/或性能更*的方法来实现相同的目标？

*GCC 4.6.1 在我的 armel v7 测试设备上，使用 -O3 优化，使用对临时变量的正常分配生成与常规代码相同的代码，但可能是我的测试用例足够简单，它能够弄清楚，如果更普遍地使用这种技术，它会变得混乱。

作为额外的兴趣，我很好奇这是否会破坏大多数与 C 兼容的语言（我知道的语言是 C++、Objective-C、D，也许还有 C#，尽管也欢迎提及其他语言)。

理由：

这就是我认为上述方法有效的原因，以防你发现知道我来自哪里有助于解释我可能犯的任何错误：

C 标准的“字节”（传统意义上的“最小可寻址内存单元”，而不是现代化的“8 位”含义）是 char 类型 - sizeof 运算符以单位为单位生成数字char。因此，我们可以通过在该变量上使用 sizeof 运算符来获得任意变量类型所需的最小存储空间（我们可以在 C 中使用）。

C 标准保证几乎所有指针类型都可以隐式转换为 void *（但如果它们的表示不同，则表示会发生变化（但顺便说一下，C 标准保证 void * 和 char * 具有相同的表示））。

就语法而言，给定类型数组的“名称”和指向同一类型的指针基本上可以同等对待。

sizeof 运算符是在编译时计算出来的，因此我们可以在不依赖有效的不可移植 VLA 的情况下执行 char foo[sizeof(bar)]。

因此，我们应该能够声明一个“字符”数组，该数组是容纳给定类型所需的最小大小。

因此，我们应该能够将要复制的变量的地址和数组的名称传递给memcpy（据我了解，数组名称隐式用作char * 到第一个元素的数组）。由于任何指针都可以隐式转换为void *（需要更改表示形式），所以这是可行的。

memcpy 应该按位复制我们要复制到数组的变量。无论类型是什么，涉及的任何填充位等，sizeof 保证我们将获取构成该类型的所有位，包括填充。

由于我们不能显式使用/声明我们刚刚复制的变量的类型，并且由于某些架构可能对各种类型有对齐要求，这种 hack 有时会违反，我们不能直接使用这个副本- 我们必须 memcpy 将它返回到我们从中获取它的变量或相同类型的变量中，以便使用它。但是一旦我们把它复制回来，我们就有了我们最初放在那里的内容的精确副本。本质上，我们正在释放变量本身以用作暂存空间。

动机（或，“天哪！？！”）：

我喜欢在有用的时候编写与类型无关的代码，但我也喜欢用 C 编写代码，将两者结合起来主要是在类似函数的宏中编写通用代码（然后你可以重新声明类型检查通过制作调用类函数宏的包装函数定义）。把它想象成 C 语言中非常粗糙的模板。

当我这样做时，我遇到了需要额外的临时空间变量的情况，但是，由于缺少可移植的 typeof() 运算符，我无法在其中声明任何匹配类型的临时变量这样的“通用宏”sn-ps 代码。这是我发现的最接近真正便携的解决方案。

由于我们可以多次执行此技巧（足够大的 char 数组，我们可以容纳多个副本，或者几个 char 数组大到足以容纳一个），只要我们可以保持 memcpy 调用并直接复制指针名称，它在功能上就像拥有任意数量的复制类型的临时变量，同时能够保持通用代码类型不可知。

附：为了稍微转移可能不可避免的判断之雨，我想说我确实认识到这非常令人费解，我只会在实践中将此保留用于经过良好测试的库代码，它显着增加了有用性，而不是什么我会定期部署。

Answer 1

是的，它有效。是的，它是 C89 标准。是的，很复杂。

小改进

字节表char[] 可以从内存中的任何位置开始。 根据 thingToCopy 的内容和 CPU，这可能会导致复制性能欠佳。

如果速度很重要（因为如果这种操作很少见，它可能不重要），您可能更喜欢使用 int、long long 或 size_t 单位来对齐表格。

主要限制

只有当您知道thingToCopy 的大小时，您的提议才有效。 这是一个主要问题：这意味着您的编译器需要知道 thingToCopy 的编译类型是什么（因此，它不能是 incomplete type）。

因此，下面这句话令人不安：

由于我们不能显式使用/声明我们刚刚复制的变量的类型

没办法。为了编译char copyPtr[sizeof(thingToCopy)];，编译器必须知道thingToCopy是什么，因此它必须能够访问它的类型！

如果你知道，你可以这样做：

thingToCopy_t save;
save = thingToCopy;
/* do some stuff with thingToCopy */
thingToCopy =  save;

阅读起来更清晰，从对齐的角度来看甚至更好。

Answer 2

在包含指针的对象上使用代码会很糟糕（指向 const 的 const 指针除外）。有人可能会修改指向的数据或指针本身（例如 realloc）。这会使您的对象副本处于意外甚至无效状态。

泛型编程是 C++ 背后的主要驱动力之一。其他人尝试使用宏和强制转换在 C 中进行泛型编程。对于小例子来说还可以，但不能很好地扩展。当您使用这些技术时，编译器无法为您捕获错误。