Почему я не могу зарезервировать 1,000,000,000 в моем векторе?
Когда я ввожу в коде foll., я получаю вывод как 1073741823.
#include <iostream>
#include <vector>
using namespace std;
int main()
{
vector <int> v;
cout<<v.max_size();
return 0;
}
Однако, когда я пытаюсь изменить размер вектора к 1,000,000,000, v.resize(1000000000); программа прекращает выполняться. Как я могу позволить программе выделить необходимую память, когда кажется, что она должна смочь?
Я использую MinGW в Windows 7. У меня есть 2 ГБ RAM. Разве это не должно быть возможно? В случае, если это не возможно, разве я не могу объявить это как массив целых чисел и уйти? НО даже который не работает.
Другая вещь состоит в том, что, предположите, что я использовал бы файл (который может легко обработать так много данных). Как я могу позволить ему читать и записать и то же время. Используя fstream file("file.txt', ios::out | ios::in ); не создает файл, во-первых. Но предположение файла существует, я не могу использовать, чтобы сделать чтение и запись одновременно. То, что я имею в виду, является этим: Позвольте содержанию файла быть 111111 Затем, если я работаю: -
#include <fstream>
#include <iostream>
using namespace std;
int main()
{
fstream file("file.txt",ios:in|ios::out);
char x;
while( file>>x)
{
file<<'0';
}
return 0;
}
Не были должны содержание файла теперь быть 101010 ? Считайте один символ и затем перезапишите следующий с 0? Или упакуйте все содержание, были считаны сразу в некоторый буфер, не должен там быть по крайней мере один 0 в файле? 1111110 ? Но содержание остается неизменным. Объясните.Спасибо.
5 ответов
32-битный процесс может адресовать адресное пространство только 4 ГБ в один раз. Обычно большая часть этого адресного пространства размером 4 ГБ используется для отображения других вещей. Ваш вектор будет занимать слишком много непрерывного адресного пространства (4 миллиарда байтов), которое вряд ли будет доступно.
Вы должны отобразить карту памяти для файла . См.
mmap.
Максимум, с которым справится реализация STL, - это одно; максимальный объем доступной из ОС памяти - это другое дело; вы попадаете в последний.
Например, вы можете создать вектор из такого количества элементов char . В любом случае не ожидайте высочайшей производительности, если у вас физически не так много памяти (плюс все, что требуется ОС и всем остальным работающим компонентам); доступ к такому вектору, несомненно, приведет к сильной перегрузке диска, поскольку система загружает и выгружает память с диска.
Также процессор с 32-битным адресным пространством (или при работе 32-битной ОС независимо от физического адресного пространства) может адресовать только 4 Гб (физический или виртуальный), поэтому существует архитектурный предел. Более того, некоторые ОС ограничивают пространство пользователя; например, размер пользовательского пространства в Win32 составляет 2 ГБ. Различные версии Win64 искусственно ограничивают пространство пользователя, чтобы позволить Microsoft устанавливать разные цены, поэтому использование Win64 не гарантирует достаточного адресного пространства.
Вы просите выделить один миллиард целых чисел в непрерывной последовательности. Помимо сложности поиска такого огромного непрерывного пространства, у вас его просто нет. Напомним, что целое число в обычной 32-битной системе занимает 32 бита или 4 байта. Умножьте это на миллиард, и вы выйдете далеко за пределы имеющихся у вас 2 ГБ. Кроме того, для std :: vector разрешено резервировать больше, чем вы запрашиваете.
Что касается вашего второго вопроса, если вы одновременно читаете и пишете с одним и тем же объектом fstream , убедитесь, что вы seekg () и seekp () перед вашим чтением и записью.
Целое число - четыре байта, поэтому 1 000 000 000 целых чисел займет около 3,72 ГБ.
Однако, когда я пытаюсь изменить размер вектора до 1 000 000 000 с помощью v.resize (1000000000); программа перестает выполняться. Как я могу позволить программе выделять требуемую память, если кажется, что она должна быть в состоянии?
Это может зависеть от реализации C ++ STL, но частое изменение размера заставляет приложение резервировать намного больше, чем вы просите.