Написал вот такую функию:



Программа компилируется и запускается. Когда начинает исполняться приведённая функция вылетает ошибка:
"Unhandled exception at 0x7c812afb in ProjectName.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012bb84" на самой первой строке с созданием массива.

Пишу в восьмой студии. Если в обоих случаях сделать на один ноль меньше, то всё отрабатывает.

Ну и вопрос остаётся прежним: "Можно ли таки создать массив длиной 1.000.000.000 байт?".

П. С. Понятно, что мою задачу в принципе можно решить и без такого длинного массива. Интересно принципиально возможно ли такое. Дельфа, например, создаёт такой массив без проблем.

EKoshelev, все зависит от платформы и системы, на которой работает программа.  В частности, 32-х битная платформа позволяет оперировать чуть более чем 4 млрд байтами.
Я не знаю, почему твоя программа падает. Возможно, необходимо что-то в настройках изменить.

А это все что вы выделяете в программе? Если не ошибаюсь (давно не обновлял для себя инфу), то под процесс выделяется базово 4Gb, с которых ситстемма сразу скушает гиг под свои нужны, потом часть памяти зарезервируется и юзеру(программеру) будет доступно 2Gb, понятно что обьем доступной памяти можно увеличить, но базово было так.

у меня на VS2010 на Win XP SP3:такая программа работает без bad_alloc, а вот уже 1 300 000 000 выделить не могу, так что смотрите в сторону увелечения HEAP для процесса, если это реально нужно

P.S. Еще есть такая опция

Это сообщение отредактировал(а) SenkraD - 31.7.2013, 11:20

Зависит от фрагментации виртуального адресного пространства программы. У меня недавно был трабл, что не мог даже 512Мб выделить одним куском. Dll-ка пакостная влезла посередине адресов и разбила самый большой кусок адресов пополам. В принципе я бы рекомендовал переселяться на 64 бита если нужны длинные массивы. Есть прожка VMMap она позволит посмотреть, кто у вас в проге главный диверсант, который разбил большой кусок адресов.

SenkraD, с хипом попробовал похимичить - ничего не вышло.


Alexeis, Ага. Пробовал 10 массивов по 100.000.000 создавать - получается. А один на млн. - фиг.

EKoshelev, можно перед запуском дефрагментатор памяти запустить.
были у меня когда-то такие маленькие утилитки (правда не пользовался, нужды не было),
в сети их должно быть.
возможно даже с исходниками, поищите.

volatile, а смысл? Системе пофиг на фрагментацию памяти, она может непрерывный блок памяти организовать хоть из ста физических блоков оперативы + еще 100 кусков свопа. Скорее всего после такого new система и не освободит гиг памяти, а будет добавлять страницы оперативы по мере появления ошибок доступа к памяти. Другое дело если в системе своп+озу в сумме не будет свободного гига. Тогда, вероятно, пойдет уже отказ по причине нехватки памяти.

Не всегда. Там есть ограничения, напр. минимальный переместимый блок, и много другой всякой мути... ...
Выше пример, наглядное тому подтверждение. память же есть, а непрерывный кусок создать не может.
пусть EKoshelev, попробует, возможно поможет.
Впрочем, утврждать что точно поможет не берусь.



Это сообщение отредактировал(а) volatile - 31.7.2013, 13:39

volatile, есть предположение, что не поможет, т.к.

Получается, что это CRT студии не может выделить, а не ОС.

2 ТС: я выделял 18 ГБ без проблем. Естественно, на 64-х битной ОС (правда не windows)

Вы думаете CRT выделяет память каким-то волшебным способом, минуя ОС?

Насчет того что дельфи выделяет, а студия нет...  мне кажется возможны несколько вариантов.
• Просто совпадение обстоятельств. Так сложилась временная конфигурация. В другой обстановке (может даже при другом порядке запуска ресурсоемких приложений) может случиться обратное.
• Возможно что просто сама IDE студии забирает под себя больше чем IDE дельфи. Программу же тестируют, при запущенной IDE... Ну и на тестируемое приложение остается меньше ресурсов. Но к качеству откомпилированного кода, ясно это не имеет отношения.

В довесок к словам Alexeis о фрагментации вирт. памяти

Миф №3
Ну и про архитектуру памяти статья.

То есть получается, большие куски могут быть разбиты доп. данными и командами. Вопрос в том, как с этим бороться..

У меня выделяет. (2008 студия) 



Это в дебаге!
В релизе так вообще до 2000 мб доходит, но я сомневаюсь что там не соптимизировалось, уж очень быстро печатает.
В дебаге каждая строчка (особенно последние) занимает ощутимое время, то есть происходит реальное выделение памяти.
Система XP 32 разр., на борту 3 гига оперативы. Запущена студия, опера, IE, и еще куча всяких мелочей.

Напомню 2 гига - теоретический предел для 32 разрядных. (можно теоретический предел увелить до 3 гб, но это надо капаться в настройкх системы.)


Цель вышеописанного теста была выяснить этот вопрос. но повторить проблему пока не удалось 

Как уже сказал Alexeis, всё зависит от фрагментации адресного пространства процесса. Если в нём будет свободный блок нужного размера - массив будет создан.


Просто Вам повезло. Например, благодаря ASLR, образы модулей, база кучи и область стека потоков разместились в адресном пространстве так, что осталось место для массива.


Основное замедление при выделении из хипа в дебаг версии занимает забивание выделенной памяти дебажной CRT сигнатурой. В придачу выделяются дополнительные байты перед и после каждого блока для детекта Heap Undelfow и Overflow(становится заметно при большом количестве мелких выделений).


Использовать х64.

Взял ваш код, откомпилил под VS 2010 32х разрядная XP и запустил, всё работает нормально.
Указывайте либо характеристики вашего компьютера (память), либо опции компиляции проекта.
Или тогда считайте, что вы сервиспак какой-то не поставили, или, что одно и то же, это какие-то родимые пятна вашего экземпляра компилятора

Это сообщение отредактировал(а) akizelokro - 5.8.2013, 06:40

А что, на платформе x64 виртаульная память по-другому распределяется с избежанием фрагментации?
Имеется ввиду как бороться с фрагментацией..

Это сообщение отредактировал(а) EgoBrain - 5.8.2013, 08:22

  На платформе 64 адресов во много раз больше чем памяти. Это получается почти как система с бесконечной памятью. Фрагментация адресного пространства начнет волновать лет через 500 . 

На 32х разрядной XP есть не очень хорошее наследство в виде болезней роста. То для видеодрайвера дыра предусмотрена, то сначала у них было одно ограничение, драйвера писались под 2Gb, ну, там заморочено.

Вообщем, у меня памяти стоит 2,5Gb, и всё компилируется.
Есть ещё возможность поиграться с опциями компилятора, /Zm например убрать и увеличить, соответственно, память для хипа. Надо не только код в таких случаях приводить, но и размер свободной памяти перед выполнением, и размер всей памяти, а также настройки проекта (опции компилятора).

Добавлено через 1 минуту и 49 секунд


На 32х разрядных серверных платформах нет ограничения в 4Gbю Тут стоит говорить именно об XP.

Добавлено через 4 минуты и 30 секунд
И даже исполняется, не только компилируется. В дебаггере проверил).

  Ну не совсем так. Если верить википедии, то 

даже в режиме PAE в рамках одного процесса адресация все равно 32х битная. PAE позволяет системе использовать более 4х Гб, но не одному процессу. 

Что-то я не понял.
Это программная технология? Но как она работает если ограничение на физическом уровне, проц (контроллер памяти) адресует память и количество "захваченных" ячеек зависит от разрядности адресного регистра.

То, что описал Alexeis, это аппаратная реализация PAE; программный механизм опирается в свою очередь на аппаратный, и если его нет, то и адресовать больше 4 ГБ x32 ОС не сможет.
Если действительно интересно, почитайте вики, там неплохо описано http://en.wikipedia.org/wiki/Physical_Address_Extension.