问题标签 [memory-layout]

我正在研究给定进程的内存布局。我注意到每个进程的起始内存位置不是0。在这个网站上，TEXT 从0x08048000开始。一个原因可能是用 NULL 指针来区分地址。我只是想知道是否还有其他好的理由？谢谢。

我尝试通过编译以下代码并检查 gdb 中的地址来验证我对 C 中堆栈内存布局的理解。我只记录最低有效数字，较高的数字相同。输出是通过使用

下面是一个简单的测试代码：

如果我查看测试功能框架，我有以下结果，

&b: 6808 &a: 6812

&c: 6824 &d: 6828

$rbp：6832（帧指针）。

我很困惑。相对于局部变量，函数参数不应该位于更高的内存地址。有人可以详细解释一下吗？谢谢。

编辑：如果我像这样打印内存：

我有

它变成了bacd order。a 的结尾和 c 的开头之间有 8 个字节的间隙。我猜应该是回邮地址吧？

有各种pragma用于控制结构/类布局的 s，例如pragma pack. 但据我所知，没有pragma理由说“我不关心布局。它是内部的，代码不依赖它。重新排序以获得最佳性能/大小。”。AFAIK，这是典型的案例，它可以在许多情况下提高性能/大小。此外，即使程序员足够小心地根据性能/大小对其重新排序，不同的目标架构也可能具有不同的最佳布局。

编辑：澄清一下，我说的是成员的顺序。填充已经是可控的。

此外，PVS-Studio 也有相关消息。这就是我要说的——为什么编译器不能用pragma?

当然，答案是“不”，因为写它的人想了很多，但我想知道为什么。

考虑到（无模板）类通常在头文件中声明，然后包含在单独编译的几个文件中，请再考虑这两个文件：

文件1.c

文件2.c

一般 Foo 会在头文件中声明并包含在两者中，但效果如上图。（也就是说，包含标题并不神奇，它只是将标题内容放在该行上。）我们可以编译两者并将它们链接到以下内容：

主文件

一种方法是使用 g++：

并且（在我的架构和环境中），这显示：8、8、8。对于 file1.cc、file2.cc 和 main.cc 的每次编译，sizeof 都是相同的

但是 c++11 标准是否保证了这一点，期望与所有 3 Foo 的布局兼容真的可以吗？Foo 包含私有和公共字段，因此它不是 c++11 标准（工作草案）的 Clause 9 par 7 中定义的标准布局结构：

标准布局类是这样的类：

• 没有非标准布局类（或此类类型的数组）或引用类型的非静态数据成员，
• 没有虚函数 (10.3) 和虚基类 (10.1)，
• 对所有非静态数据成员具有相同的访问控制（第 11 条），
• 没有非标准布局的基类，
• 要么在派生最多的类中没有非静态数据成员，并且最多有一个具有非静态数据成员的基类，要么没有具有非静态数据成员的基类，并且
• 没有与第一个非静态数据成员相同类型的基类。

由于我们使用的是结构，并且为了彻底，下一个标准说：

标准布局结构是使用 class-key 结构或 class-key 类定义的标准布局类。标准布局联合是使用类键联合定义的标准布局类。

据我所知，该标准仅定义标准布局中结构之间的布局兼容性（第 9.2 条，第 18 条）。

如果两个标准布局结构（第 9 条）类型具有相同数量的非静态数据成员并且相应的非静态数据成员（按声明顺序）具有布局兼容类型（3.9），则它们是布局兼容的。

那么是否保证所有三个 Foo 都是布局兼容的，更重要的是为什么？

为什么在编译期间为 Foo 创建不同布局的（非确定性）编译器不是 c++11 编译器？

我需要将它沿0维度求和，但在现实世界中，矩阵是巨大的，我更愿意沿-1维度求和，这由于内存布局而更快。因此，我希望将结果转置：

我怎么做？我希望 numpy 的“高级索引”的结果被隐式转置。最后明确地转.T置它甚至更慢，不是一种选择。

Update1：​​在现实世界中，高级索引是不可避免的，并且下标不保证相同。

Update2：为了澄清这不是XY 问题，这里是实际问题：

我有一个大矩阵X，其中包含x来自某些概率分布的元素。元素的概率分布取决于元素的邻域。这个分布是未知的，所以我遵循Gibbs 抽样程序来构建一个矩阵，其中包含来自这个分布的元素。简而言之，这意味着我对矩阵进行了一些初步猜测X，然后我不断迭代矩阵的元素，并使用取决于 的相邻值的公式X更新每个元素。因此，对于矩阵的任何元素，我需要获取其邻居（高级索引）并对它们执行一些操作（在我的示例中求和）。我用过xxline_profiler看到在我的代码中花费大部分时间的行是取数组相对于维度的总和，0而不是-1. 因此，我想知道是否有一种方法可以通过高级索引生成已经转置的矩阵。

考虑

如果结束标记是在数组之后定义的，是否可以保证

我不想手动计算数据中元素的数量。

它碰巧在 gdb 中看起来不错，没有任何优化选项，但在使用它之前，我需要知道编译器无法移动data_end. 如果可以，我该怎么做。

是否有一种通用方法（不依赖于平台）在编译时获取内存中类对象的大小，而不计算 vtable 指针？

假设我有一个以unsigned int;为键的关联数组 值可以是任何固定大小的类型。有一些预定义的最大数量。的实例。

API 使用示例：MyStruct * valuePtr = get(1234);和put(6789, &myStructInstance);...基本。

当我从这个数组中快速随机读取条目时，我想尽量减少缓存未命中，所以我预先malloc(sizeof(MyType) * MAX_ENTRIES)尽可能确保引用的局部性。

泛型对于 values 数组很重要。我看过C pseudo-generics，但void *为了简单起见更喜欢；但是，不确定这是否与性能目标不一致。最终，我想知道什么最适合性能。

我应该如何实现关联数组以提高性能？到目前为止的想法...

• 我是否将关联数组传递void *给 ed values 数组的单个指针malloc并允许它在内部使用它（为此我们需要保证匹配的键数组大小）？我可以一般地这样做吗，因为需要知道类型（？）才能索引到值数组？
• 我是否void * valuePtrs[]在关联数组中有一个单独的，然后让这些指针指向malloced values 数组中的每个元素？这似乎可以避免需要了解具体类型？
• 我是否使用C 伪泛型并因此允许get()返回特定的值类型？当然，在这种情况下，唯一的好处是不必显式转换，例如MyStruct* value = (MyStruct*) get(...)......数组元素仍然必须被取消引用，因此具有相同的开销？

而且，一般来说，上述最小化 cahce 未命中的方法似乎有意义吗？

我正在定义要通过不同设备和不同编程语言之间的通信通道接收和发送的结构。为此，我使用StructLayoutAttribute明确定义它们在内存中的布局（顺序，pack=1 - 以防万一）。

从文档中，我知道它在结构仅包含字段时有效。它似乎也适用于“简单”属性（使用空 get; set;）。但是我不知道是否总是这样。

所以我关于 StructLayoutAttribute 对属性的影响的问题分为两个：

1. 简单的属性（同样是空的 get;set;）的行为是否与字段相同？
2. 其他属性如何表现，例如，他们获得的属性是对其他属性的计算？它们是否被忽略（因为我没有看到它们背后的实际数据项）？他们有记忆吗？

所以我一直在阅读这两篇文章和这个答案

无法将 []string 转换为 []interface {}表示需要更改内存布局。

http://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go说理解底层内存可以很容易地回答这个问题，并且

http://research.swtch.com/interfaces解释了幕后发生的事情。

但是对于我的生活，我想不出一个原因，就接口的实现而言，为什么 []T 不能转换为 []interface。

所以为什么？