关于 pair 在编译时的内存计算和占用

学术版

Shunpower @ 2024-10-17 18:55:49

RT。

众所周知，在结构体中声明变量需要进行繁杂的内存对齐。

对于如下代码：

struct hashtable{
    const int mod = 2e7 + 3, base = 503; 
    pair <ll, int> umap[20000010];
} T;

一部分编译器显示 out of memory，一部分编译器疑似死循环（比如我的 GCC9.2），或者也可能是编译时间过长。

然而：

struct hashtable{
    const int mod = 2e7 + 3,base = 503;
    ll umap[20000010];
} T;

struct hashtable{
    const int mod = 2e7 + 3,base = 503;
    ll umap[20000010];
    int um[20000010];
} T;

struct hashtable{
    const int mod = 2e7 + 3,base = 503;
    int um[80000040];
} T;

都可以在相当快的时间内完成编译。

这是 pair 的对齐方式的问题吗？

by DeepSkyCore @ 2024-10-17 18:59:14

神秘，不过

const int mod = 2e7 + 3, base = 503; 
struct hashtable{
    pair <ll, int> umap[20000010];
} T;

或者

namespace T{
    const int mod = 2e7 + 3, base = 503; 
    pair <ll, int> umap[20000010];
}

好像都没问题

by jason_sun @ 2024-10-17 19:04:54

结构体确实挺神秘的，之前结构体里面定义umap，加cerr就RE，不加就正常

by yukimianyan @ 2024-10-17 19:24:24

struct hashtable{
    static constexpr int mod = 2e7 + 3, base = 503; 
    pair <ll, int> umap[20000010];
} T;

你第一个代码，umap 数组被放进 .data 段里面了，编译出来的可执行文件超级大

by yukimianyan @ 2024-10-17 19:24:57

这可能不是对齐的问题，是初始化器（尤其是默认成员初始化器）的问题 /yun

by yukimianyan @ 2024-10-17 19:29:57

这是不是跟 int inv[10000010] = {0, 1} 一个性质的问题 /yun 不知道为什么啊

by DeepSkyCore @ 2024-10-17 19:34:01

@yukimianyan struct 里面真的可以放 const int 吗，感觉从来没了解过/ll

by yukimianyan @ 2024-10-17 19:35:17

@DeepSkyCore 当然可以（？）和一般的非静态成员一样的待遇（？？？）

by Shunpower @ 2024-10-18 06:42:19

@yukimianyan 明白了感谢/bx