我同意上面的观点，如果你用

 int myArray[SIZE] 

那么SIZE受限于一个整数的大小。但是你总是可以malloc一个内存块，并有一个指向它的指针，只要malloc不返回NULL。

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

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

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

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

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

有一件事我认为在之前的回答中没有提到。

当人们在设计中使用这些东西时，我总是感觉到重构的“臭味”。

这是一个巨大的数组，从效率和性能的角度来看，这可能不是表示数据的最佳方式。

欢呼,

Rob

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

有两个限制，都不是由c++强制执行的，而是由硬件强制执行的。

第一个限制(不应达到)由用于描述数组中索引的size类型的限制(及其大小)设置。它由系统std::size_t可以接受的最大值给出。此数据类型足够大，可以包含任何对象的字节大小

另一个限制是物理内存限制。数组中的对象越大，这个限制就越快达到，因为内存已经满了。例如，给定大小为n的vector<int>通常占用的内存是vector<char>(减去一个小常量值)类型数组的数倍，因为int通常比char大。因此，在内存满之前，<char>的向量可能包含比<int>的向量更多的项。对于原始c风格数组，如int[]和char[]，也是如此。

此外，这个上限可能受到用于构造vector的分配器类型的影响，因为分配器可以自由地以任何它想要的方式管理内存。一个非常奇怪但仍然可以想象的分配器可以以这样一种方式池内存，即对象的相同实例共享资源。通过这种方式，您可以将许多相同的对象插入到容器中，否则将耗尽所有可用内存。

除此之外，c++没有强制任何限制。

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... :-)