Здравствуйте, _hum_, Вы писали:

__>Я правильно понимаю, при выделении памяти под данные std::vector требуется линейный отрезок, а потому даже если операционная система показывает достаточное для размещения данных этого вектора память, это не означает, что вектор может быть создан (типа, куча дефрагментирована)?

Да.

__>И если да, то есть ли какие-то стандарты на менеджер кучи (ну там, что он всегда доступную память переупорядочивает так, чтобы свободная представляла собой один линейный отрезок, и т.п.).

Не может оно ничего переупорядочить, на выделенное уже указатели заведены, которые менеджер кучи не контролирует. Это вам не хандлы в жабе.
Если нужно ужиматься в куски, можно попробовать другие контейнеры, экстремальный вариант — список, когда на каждый элемен своё выделение. Но тут можете сильно проиграть, если сами элементы маленькие. Или дек, он вроде бы как раз кусками выделяет.

__>Мне просто, чтоб понять, почему может происходить экспепшн bad_alloc при видимом в диспетчере задач наличии свободной ОЗУ. Например, вот мне прислали график загрузки памяти при работе моей проги до вылета bad_alloc на моменте, когда она должна была запросить память, равную памяти того, что скушала на данный момент (вроде бы, по картинке, место еще было):

Стандартно, для нормальной работы менеджера памяти требуется минимум вдвое больше памяти, чем максимально будет выделено. А лучше — в четыре. Или заводите себе сами сразу всё большое, что понадобится при работе, лучше одним куском, чтобы с извратами типа ASLR не столкнуться.

Здравствуйте, _hum_, Вы писали:

__>И если да, то есть ли какие-то стандарты на менеджер кучи (ну там, что он всегда доступную память переупорядочивает так, чтобы свободная представляла собой один линейный отрезок, и т.п.).

Соседние свободные куски сливаются практически в любом менеджере кучи. А чтобы слить несоседние, надо уметь занятые передвигать, а как это сделаешь в C++, если ссылки на них могут прятаться, где угодно?

__>Мне просто, чтоб понять, почему может происходить экспепшн bad_alloc при видимом в диспетчере задач наличии свободной ОЗУ. Например, вот мне прислали график загрузки памяти при работе моей проги до вылета bad_alloc на моменте, когда она должна была запросить память, равную памяти того, что скушала на данный момент (вроде бы, по картинке, место еще было):

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

Я правильно понимаю, при выделении памяти под данные std::vector требуется линейный отрезок, а потому даже если операционная система показывает достаточное для размещения данных этого вектора память, это не означает, что вектор может быть создан (типа, куча дефрагментирована)?
И если да, то есть ли какие-то стандарты на менеджер кучи (ну там, что он всегда доступную память переупорядочивает так, чтобы свободная представляла собой один линейный отрезок, и т.п.).

Мне просто, чтоб понять, почему может происходить экспепшн bad_alloc при видимом в диспетчере задач наличии свободной ОЗУ. Например, вот мне прислали график загрузки памяти при работе моей проги до вылета bad_alloc на моменте, когда она должна была запросить память, равную памяти того, что скушала на данный момент (вроде бы, по картинке, место еще было):

Здравствуйте, _hum_, Вы писали:

__>Я правильно понимаю, при выделении памяти под данные std::vector требуется линейный отрезок, а потому даже если операционная система показывает достаточное для размещения данных этого вектора память, это не означает, что вектор может быть создан (типа, куча дефрагментирована)?
__>И если да, то есть ли какие-то стандарты на менеджер кучи (ну там, что он всегда доступную память переупорядочивает так, чтобы свободная представляла собой один линейный отрезок, и т.п.).

__>Мне просто, чтоб понять, почему может происходить экспепшн bad_alloc при видимом в диспетчере задач наличии свободной ОЗУ. Например, вот мне прислали график загрузки памяти при работе моей проги до вылета bad_alloc на моменте, когда она должна была запросить память, равную памяти того, что скушала на данный момент (вроде бы, по картинке, место еще было):
__>Image: c088a83ef536.jpg

Запуск 32-х битного процесса в 64-битном окружении?

Здравствуйте, SaZ, Вы писали:

SaZ>Запуск 32-х битного процесса в 64-битном окружении?

Возможно. Спасибо за идею.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, _hum_, Вы писали:

__>>И если да, то есть ли какие-то стандарты на менеджер кучи (ну там, что он всегда доступную память переупорядочивает так, чтобы свободная представляла собой один линейный отрезок, и т.п.).

Pzz>Соседние свободные куски сливаются практически в любом менеджере кучи. А чтобы слить несоседние, надо уметь занятые передвигать, а как это сделаешь в C++, если ссылки на них могут прятаться, где угодно?


А что за проблема с C++ на Windows? Указатели ведь на виртуальную память,
поэтому менеджер кучи может освободить неиспользуемую страницу или несколько в "дырке",
и ОС отмапит этот незанятый кусок куда-нибудь еще.

Здравствуйте, Zhendos, Вы писали:

Z>А что за проблема с C++ на Windows? Указатели ведь на виртуальную память,
Z>поэтому менеджер кучи может освободить неиспользуемую страницу или несколько в "дырке",
Z>и ОС отмапит этот незанятый кусок куда-нибудь еще.

Это еще нужно, чтобы у тебя целая страница была свободная. Но в принципе, современные менеджеры кучи умеют, говорят, возвращать память системе.

Здравствуйте, Zhendos, Вы писали:

Z>А что за проблема с C++ на Windows? Указатели ведь на виртуальную память,
Z>поэтому менеджер кучи может освободить неиспользуемую страницу или несколько в "дырке",
Z>и ОС отмапит этот незанятый кусок куда-нибудь еще.

Так ведь 32-битное пространство не резиновое.

Да и вообще, совершенно неважно, что творится под капотом ОС. Если менеджер кучи недостаточно умный, чтобы избегать фрагментации, то вполне может получиться так, что образуется много маленьких дырок большим общим размером.
При достаточно большом времени работы можно и 64-битное пространство издырявить.

Умные менеджеры кучи стараются выделять память под мелкие блоки в одних страницах, а под крупные — в других.
Тогда освобождение нескольких крупных блоков с большей вероятностью приведёт к образованию сплошной большой дырки.