Вы все еще захватываете сбои выделения памяти в своей [закрытой] программе C++

Я действительно захватываю выделения памяти, но только иногда.

В частности, я буду иногда захватывать выделение памяти где:

• Я знаю, что выделяемый объем памяти является очень большим
• Существует что-то, что я могу делать с этим, если выделение перестало работать (т.е.: корректно обработайте условие с уведомлением пользователю, и т.д.),

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

В целом не проверяйте на сбои выделения памяти на маленьких выделениях. Неизбежно, это - больше проблемы, чем это стоит, и трудно разобраться так или иначе. И большую часть времени нет ничего, что можно делать с этим. На операциях очень памяти большой емкости, если можно делать с этим что-то, это могли бы быть вещи достойные рассмотрения в зависимости от конкретного случая.

Это хорошо покрыто Глюками C++: Предотвращение Типичных проблем в Кодировании и Дизайне. В частности, посмотрите Глюк № 61: Проверка Отказ Выделения:

Некоторые вопросы нельзя просто задать, и успешно выполнилось ли конкретное выделение памяти, один из них.

[...] Проверка ошибок кодирует, это, включенный редко совершенно корректен первоначально и почти никогда не корректен после периода обслуживания. Лучший подход не должен проверять вообще:

String **array = new String *[n];
for( String **p = array; p < array+n; ++p )
  *p = new String;

Этот код является короче, более четким, быстрее, и корректным. Стандартное поведение новых состоит в том, чтобы выдать bad_alloc исключение в случае отказа выделения. Это позволяет нам инкапсулировать код обработки ошибок для отказа выделения от остальной части программы, приводящей к инструменту для очистки, более четкому, и обычно более эффективному дизайну.

Если Вы не сделаете некоторые довольно впечатляющие выделения, Вы вряд ли поразите отказ выделения в 32-разрядном пространстве виртуальной памяти. (И еще менее вероятно в 64 битах syste). Вероятно, лучше просто умереть, если у Вас заканчивается память. В редком случае, что что-то идет не так, как надо и у Вас действительно заканчивается память, Вы вряд ли сможете сообщить об ошибке так или иначе. (Если, конечно, Вы конкретно не откладываете резерв памяти заранее к свободному в случае отказа выделения.)

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

При ловле Вашего из исключения памяти, можно получить отслеживание стека, где отказ произошел, который 99% времени - все, что необходимо диагностировать проблему. Это - затем Ваш журнал.

Вы можете, чтобы заблокировать от буфера 1 МБ или чего-то, что можно использовать для генерации этой информации, или при помощи его непосредственно или при помощи выпуска его так, память становится доступной при создании журнала.

Да я делаю, но это зависит от Вашего приложения. Для важных приложений, большого количества приложений для сервера и сервисов, работающих на клиентской системе, Вы абсолютно не должны отказывать в случаях OOM - из условий памяти, может возникнуть временно, и пользователь ожидал бы, что Ваш код для продолжания бегать за проблемой разрешает.

Вообразите, начинает ли один пожиратель ресурсов памяти работать на Вашей системе, и внезапно Вашей оболочке, Вашем веб-браузере, приложениях, и т.д., сбое из-за этого. Это не было бы пользой пользовательский опыт вообще.

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

Независимо, даже для необработанного случая необходимо добавить высокоуровневую выгоду, которая может сделать некоторый вход в конечном счете, OOM на самом деле вызывается кодом.

На современной ОС Ваш компьютер заморозится и вероятно падать долго, задолго до того, как у Вас на самом деле заканчивается VM. Это - бессмысленное тестирование на него.

В случае на 99,9% все мои приложения C++ просто умрут на неудавшемся выделении. После того как Вы вне памяти, действительно нет ничего, что можно сделать, если приложение не специально предназначено, чтобы обработать и исправить из условий памяти.

Случай на.1% для случаев, где выделение делается, который 1) известно, является очень большим и имеет значительный шанс отказа и 2) представляет ситуацию, где соответствующая нейтрализация является соответствующей. Это очень редко, и это были годы, с тех пор как я попробовал что-то как это (я, woludn't делают это снова).

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

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

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

Согласно другому предложению, я даю настоящий ответ.

До сих пор во многих предложениях в основном говорилось, что «bad_alloc == ошибка в вашей программе». Напротив, выбросы bad_alloc не всегда указывают на ошибку.

В качестве примера я разрабатываю редактор карт для игрового проекта, над которым я работаю. Иногда при больших размерах карты выдается bad_alloc. Это не указывает на ошибку, просто размеры карт слишком велики, чтобы поместиться в доступной памяти на компьютере пользователя. Вряд ли это тот случай, когда я хочу, чтобы программа аварийно завершила работу, и это очень легко исправить с помощью простого блока try / catch при создании карты с оператором new. Если это не удается, просто я освобождаю всю оставшуюся память и с удовольствием продолжаю работу. Конечно, не все случаи bad_alloc настолько прямолинейны, поэтому важно действительно понимать, почему выбрасывается bad_alloc.