Проблема с MS VS 2015. Предел ореративной памяти.

[MGM]

Компьтер имеет 64GB ОП.
В части кода программа С++ под MS VS 2015 выделяет место под массивы, и где-то в середине этого процесса код вылетает по exception std::bad_alloc;
На момент перывания используется только 8GB, а студия выходит только на 2 гига и выдаёт:
Unhandled exception at 0x7681A932 in segment.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0137E8B0.
Не совсем понятно, в чём проблема. Может надо поменять установки?

[EtCetera]

Судя по всему, Вы компилируете Win32-приложение, которому доступно только 2 Гб памяти под Windows. Впрочем, настроить проект для компиляции под x64 довольно легко. Вот с самим кодом при этом могут возникнуть разнообразные проблемы.

[MGM]

Спасибо. Попробую. Однако Windows у меня x64, да и версия VS тоже как бы.
Другое дело, что про второй компьютер, выходящий на тотже проект в dropbox, я не в курсе, пока.

-- Чт май 04, 2017 20:09:02 --

Нет. Ошибся. x64 у меня не активирован.

[MGM]

EtCetera в сообщении #1214095 писал(а):

Судя по всему, Вы компилируете Win32-приложение, которому доступно только 2 Гб памяти под Windows. Впрочем, настроить проект для компиляции под x64 довольно легко. Вот с самим кодом при этом могут возникнуть разнообразные проблемы.

Да. Проблемы возникли сразу.
А главное в библиотеках которые я не писал. Возможно и везде, просто пока линковщик не видит одну.

[EtCetera]

MGM в сообщении #1214122 писал(а):

А главное в библиотеках которые я не писал. Возможно и везде, просто пока линковщик не видит одну.

Это как раз из разряда относительно несложных проблем. Для компиляции x64-проекта нужны x64-библиотеки. Т.е. их либо надо где-то взять уже скомпилированными, либо скомпилировать самому из исходников. А затем в Вашем проекте прописать пути к x64-вариантам библиотек для конфигурации x64.
Вообще, поддерживать настройки проекта в актуальном состоянии для 4-х конфигураций (Debug/Release × Win32/x64) м.б. накладно, поэтому имеет смысл задуматься об использовании Property Sheets или даже какой-нибудь системы автоматизации сборки, например, CMake.

-- Чт май 04, 2017 20:21:08 --

MGM в сообщении #1214101 писал(а):

Однако Windows у меня x64, да и версия VS тоже как бы.

Кстати говоря, сама Visual Studio по-прежнему остается Win32-приложением.

[MGM]

EtCetera в сообщении #1214124 писал(а):

MGM в сообщении #1214122 писал(а):

А главное в библиотеках которые я не писал. Возможно и везде, просто пока линковщик не видит одну.

Это как раз из разряда относительно несложных проблем. Для компиляции x64-проекта нужны x64-библиотеки. Т.е. их либо надо где-то взять уже скомпилированными, либо скомпилировать самому из исходников. А затем в Вашем проекте прописать пути к x64-вариантам библиотек для конфигурации x64.
Вообще, поддерживать настройки проекта в актуальном состоянии для 4-х конфигураций (Debug/Release × Win32/x64) м.б. накладно, поэтому имеет смысл задуматься об использовании Property Sheets или даже какой-нибудь системы автоматизации сборки, например, CMake.

-- Чт май 04, 2017 20:21:08 --

MGM в сообщении #1214101 писал(а):

Однако Windows у меня x64, да и версия VS тоже как бы.

Кстати говоря, сама Visual Studio по-прежнему остается Win32-приложением.

(Оффтоп)

Несложно понятие относительное. Исходники библиотек есть, но они сами ссылаются на библиотеки IO-png и всё это полусамопал различных исследовательских групп. Врядли они сейчас поддерживают именно этот формат, так как тренд работы с изображениями сильно изменился за последнее время. Тем более, что именно сейчас мне бы не хотелось этим заниматься: дедлайн.

А вот кто-нибудь знает, почему лимит VS 2017 всего 2ГБ? Ведь разрядность 32 позволяет использовать 4ГБ?
Нельзя ли настроить VS хотябы на 3ГБ? Что-то такое в сети попадалось.

[aa_dav]

MGM в сообщении #1214238 писал(а):

А вот кто-нибудь знает, почему лимит VS 2017 всего 2ГБ? Ведь разрядность 32 позволяет использовать 4ГБ?

Ну я в общих чертах знаю.
Когда проектировали ядро WinNT типичными объёмами ОЗУ компа были единицы и десятки мегабайт и гигабайты казались чем то заоблачным.
В процессе мозгового штурма была выработана схема, когда верхний бит 32-битного адреса как бы означал, что эта часть адресного пространства используется ядром. И такие адреса процессам не давались в принципе. Плюс еще маппинг портов ввода-вывода на ОЗУ какую то роль сыграл вроде бы тоже, но тут не знаю толком и могу приврать.
В дальнейшем при развитии технологий поняли, что 2Гб мало и сделали спец-опцию в ядре, позволяющую отдавать процессам до 3Гб ОЗУ. 1Гб всё равно так и остался недоступен процессам.
Надо заметить, что WinXP надо запускать с этой опцией - это выбирается в настройках системы, называется вроде бы PAE. Но еще и сам exe-шник (32-битный) должен быть скомилирован так, что в нём в заголовке EXE включена такая галка - иначе тоже не заведется технология. Но если обе карты совпадут, то процесс сможет скушать примерно 3Гб ОЗУ.

[EtCetera]

MGM в сообщении #1214238 писал(а):

А вот кто-нибудь знает, почему лимит VS 2017 всего 2ГБ?

Мне казалось, вначале речь шла про VS 2015? Впрочем, это неважно.

MGM в сообщении #1214238 писал(а):

Нельзя ли настроить VS хотябы на 3ГБ? Что-то такое в сети попадалось.

Вы имеете в виду, что необходимо настроить проект так, чтобы скомпилированная Win32-программа могла использовать больше 2 Гб оперативной памяти? Попробуйте воспользоваться опцией линковщика /LARGEADDRESSAWARE (правда, это может обернуться игрой со спичками).

[bondkim137]

Некоторые фреймворки адаптиврованы под x64 частично. Т.е. Памяти суммарно выделять можно сколько угодно, но за раз (и массивы соответсвенно) не могут превышать 2^{32 - 1}-1
Известные мне VS-овские встроенные фреймворки этим не страдают.

Без шаманства на 32-х разрядной пользовательской OS Windows можно утилизировать до 3GB оперативной памяти, процессу при этом дается только те же 2GB адресного пр-ва.