没有人提到堆栈帧的大小限制。

有两个地方可以分配内存:

在堆上(动态分配内存)。 这里的大小限制是可用硬件和操作系统通过使用其他设备临时存储未使用的数据(即将页面移动到硬盘)来模拟空间的能力的组合。 在堆栈上(局部声明的变量)。 这里的大小限制是编译器定义的(可能有硬件限制)。如果你阅读编译器文档，你经常可以调整这个大小。

因此，如果你动态分配一个数组(限制很大，详见其他文章)。

int* a1 = new int[SIZE];  // SIZE limited only by OS/Hardware

或者，如果数组分配在堆栈上，则受限于堆栈帧的大小。注意:vector和其他容器在堆栈中存在的很小，但通常大部分数据都在堆上。

int a2[SIZE]; // SIZE limited by COMPILER to the size of the stack frame

从实际而非理论的角度来看，在32位Windows系统上，单个进程可用的最大内存总量是2 GB。您可以通过使用具有更多物理内存的64位操作系统来打破这个限制，但是是这样做还是寻找替代方案在很大程度上取决于您的预期用户和他们的预算。您还可以使用PAE对其进行某种程度的扩展。

数组的类型非常重要，因为许多编译器上的默认结构对齐是8字节，如果内存使用有问题，这是非常浪费的。如果你使用Visual c++瞄准Windows，可以使用#pragma pack指令来克服这个问题。

另一件要做的事情是看看哪些内存压缩技术可以帮助你，比如稀疏矩阵，动态压缩等等……这也是高度依赖于应用程序的。如果你编辑你的文章来提供更多关于数组中实际内容的信息，你可能会得到更有用的答案。

Edit: Given a bit more information on your exact requirements, your storage needs appear to be between 7.6 GB and 76 GB uncompressed, which would require a rather expensive 64 bit box to store as an array in memory in C++. It raises the question why do you want to store the data in memory, where one presumes for speed of access, and to allow random access. The best way to store this data outside of an array is pretty much based on how you want to access it. If you need to access array members randomly, for most applications there tend to be ways of grouping clumps of data that tend to get accessed at the same time. For example, in large GIS and spatial databases, data often gets tiled by geographic area. In C++ programming terms you can override the [] array operator to fetch portions of your data from external storage as required.

我会通过创建一个2d动态数组来解决这个问题:

long long** a = new long long*[x];
for (unsigned i = 0; i < x; i++) a[i] = new long long[y];

更多信息请访问https://stackoverflow.com/a/936702/3517001

尽管目前所有的答案都不明确，但令人恼火的是，它们大多是正确的，但也有许多不常被提及的警告。要点是，你有两个上限，其中只有一个是真正定义的，所以YMMV:

1. 编译时的限制

基本上，你的编译器将允许什么。对于x64 Windows 10盒子上的Visual c++ 2017，这是我在产生2GB限制之前的编译时的最大限制，

unsigned __int64 max_ints[255999996]{0};

如果我这样做，

unsigned __int64 max_ints[255999997]{0};

我得到:

错误C1126自动分配超过2G

我不确定2G如何与255999996/7相关联。我谷歌了这两个数字，我能找到的唯一可能相关的是这个关于dc精度问题的*nix问答。不管怎样，你要填充哪种类型的int数组似乎并不重要，重要的是可以分配多少元素。

2. 运行时的限制

你的堆栈和堆有它们自己的限制。这些限制都是基于可用的系统资源以及应用本身的“重量”而改变的值。例如，使用我当前的系统资源，我可以运行这个:

int main()
{
    int max_ints[257400]{ 0 };
    return 0;
}

但如果我稍微调整一下……

int main()
{
    int max_ints[257500]{ 0 };
    return 0;
}

砰!堆栈溢出!

在memchk.exe中的0x00007FF7DC6B1B38抛出异常:0xC00000FD: 堆栈溢出(参数:0x0000000000000001, 0x000000AA8DE03000)。 在memchk.exe中的0x00007FF7DC6B1B38未处理的异常:0xC00000FD: 堆栈溢出(参数:0x0000000000000001, 0x000000AA8DE03000)。

为了详细说明你的应用点的沉重程度，这是很好的:

int main()
{
    int maxish_ints[257000]{ 0 };
    int more_ints[400]{ 0 };
    return 0;
}  

但是这会导致堆栈溢出:

int main()
{
    int maxish_ints[257000]{ 0 };
    int more_ints[500]{ 0 };
    return 0;
}  

没有人提到堆栈帧的大小限制。

有两个地方可以分配内存:

在堆上(动态分配内存)。 这里的大小限制是可用硬件和操作系统通过使用其他设备临时存储未使用的数据(即将页面移动到硬盘)来模拟空间的能力的组合。 在堆栈上(局部声明的变量)。 这里的大小限制是编译器定义的(可能有硬件限制)。如果你阅读编译器文档，你经常可以调整这个大小。

因此，如果你动态分配一个数组(限制很大，详见其他文章)。

int* a1 = new int[SIZE];  // SIZE limited only by OS/Hardware

或者，如果数组分配在堆栈上，则受限于堆栈帧的大小。注意:vector和其他容器在堆栈中存在的很小，但通常大部分数据都在堆上。

int a2[SIZE]; // SIZE limited by COMPILER to the size of the stack frame

To summarize the responses, extend them, and to answer your question directly: No, C++ does not impose any limits for the dimensions of an array. But as the array has to be stored somewhere in memory, so memory-related limits imposed by other parts of the computer system apply. Note that these limits do not directly relate to the dimensions (=number of elements) of the array, but rather to its size (=amount of memory taken). Dimensions (D) and in-memory size (S) of an array is not the same, as they are related by memory taken by a single element (E): S=D * E. Now E depends on:

数组元素的类型(元素可以更小也可以更大) 内存对齐(为了提高性能，元素被放置在某个值的倍数的地址上，这会引入 元素之间的“浪费空间”(填充) 对象静态部分的大小(在面向对象编程中，相同类型对象的静态组件只存储一次，与此类相同类型对象的数量无关)

Also note that you generally get different memory-related limitations by allocating the array data on stack (as an automatic variable: int t[N]), or on heap (dynamic alocation with malloc()/new or using STL mechanisms), or in the static part of process memory (as a static variable: static int t[N]). Even when allocating on heap, you still need some tiny amount of memory on stack to store references to the heap-allocated blocks of memory (but this is negligible, usually). The size of size_t type has no influence on the programmer (I assume programmer uses size_t type for indexing, as it is designed for it), as compiler provider has to typedef it to an integer type big enough to address maximal amount of memory possible for the given platform architecture. The sources of the memory-size limitations stem from

进程可用的内存数量(对于32位应用程序，即使在64位操作系统内核上，也仅限于2^32字节)， 进程内存的划分(例如，为堆栈或堆设计的进程内存的数量)， 物理内存的碎片化(许多分散的小的空闲内存片段不适用于存储一个整体结构)， 物理内存的数量， 以及虚拟内存的数量。

They can not be ‘tweaked’ at the application level, but you are free to use a different compiler (to change stack size limits), or port your application to 64-bits, or port it to another OS, or change the physical/virtual memory configuration of the (virtual? physical?) machine. It is not uncommon (and even advisable) to treat all the above factors as external disturbances and thus as possible sources of runtime errors, and to carefully check&react to memory-allocation related errors in your program code. So finally: while C++ does not impose any limits, you still have to check for adverse memory-related conditions when running your code... :-)