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

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

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

欢呼,

Rob

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

 int myArray[SIZE] 

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

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

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

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

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

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

正如许多优秀的答案所指出的，有很多限制取决于你的c++编译器版本、操作系统和计算机特性。但是，我建议使用以下Python脚本检查机器上的限制。

它使用二进制搜索，并在每次迭代中通过创建一个尝试创建该大小的数组的代码来检查中间大小是否可行。脚本尝试编译它(对不起，这部分只在Linux上工作)，并根据成功与否调整二进制搜索。看看吧:

import os

cpp_source = 'int a[{}]; int main() {{ return 0; }}'

def check_if_array_size_compiles(size):
        #  Write to file 1.cpp
        f = open(name='1.cpp', mode='w')
        f.write(cpp_source.format(m))
        f.close()
        #  Attempt to compile
        os.system('g++ 1.cpp 2> errors')
        #  Read the errors files
        errors = open('errors', 'r').read()
        #  Return if there is no errors
        return len(errors) == 0

#  Make a binary search. Try to create array with size m and
#  adjust the r and l border depending on wheather we succeeded
#  or not
l = 0
r = 10 ** 50
while r - l > 1:
        m = (r + l) // 2
        if check_if_array_size_compiles(m):
                l = m
        else:
                r = m

answer = l + check_if_array_size_compiles(r)
print '{} is the maximum avaliable length'.format(answer)

您可以将它保存到您的机器并启动它，它将打印您可以创建的最大尺寸。我的机器是2305843009213693951。

从实际而非理论的角度来看，在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.

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

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

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

欢呼,

Rob