Как часто Вы проверяете на исключение в C++ новую инструкцию?

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

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

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

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

Никогда нет одного ответа на это. Это - выбор, который необходимо сделать, в зависимости от контекста как всегда.

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

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

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

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

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

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

В системе с помощью виртуальной памяти, malloc () не возвратит ПУСТОЙ УКАЗАТЕЛЬ, и новый не возвратит станд.:: bad_alloc; они возвратят виртуальный адрес. Когда Вы запишете в зону памяти, на которую указывает этот адрес, система попытается отобразить виртуальный адрес на физический адрес. Если больше не будет доступной памяти, то Вы получите отсутствие страницы.

Таким образом, Вы ловите для станд.:: bad_alloc, когда Вы находитесь во встроенной системе без MMU и надеетесь, что можно сделать что-то для освобождения некоторой памяти.

Это обычно не стоит, если Вы не используете что-то как RAII (Приобретение Ресурса Является Инициализацией), шаблон. В этом случае Вы, вероятно, выделяете удаленные ресурсы в конструкторе, который может включать использование, новое для создания большого буфера.

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

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

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

Я думаю, что это в основном зависит от типа приложений, которые Вы пишете. Если я записал бы что-то, что не влияет на глобальную устойчивость системы, скажем, игра или проигрыватель фильмов, я не проверил бы на то исключение. Мое приложение звонило бы std::terminate и я мог зарегистрировать его где-нибудь, или мое ядро закроет мою программу сначала для создания места для других программ.

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

Я думаю, что это все зависит от пропорциональности. Что Вы получаете от удивительно стабильного проигрывателя фильмов, если он начинает замедляться для проигрывания фильмов из-за агрессивной проверки?

Btw, кто-то ответил, что malloc не возвратится 0, когда Вы будете вне памяти для некоторых систем. Правильно, но поскольку страница справочника malloc указывает (конкретный Linux)

В случае, если Linux используется при обстоятельствах, где было бы менее желательно внезапно потерять некоторые случайным образом выбранные процессы, и кроме того версия ядра является достаточно последней, можно выключить это поведение чрезмерных обязательств с помощью команды как: $ echo 2 > /proc/sys/vm/overcommit_memory

См. также каталог Documentation ядра, файлы vm/overcommit-accounting и sysctl/vm.txt.

Это раньше было, что Ваша программа умерла от смерти подкачки путь перед выделением последнего байта с жестким диском, получающим доступ к файлу подкачки размер адресного пространства. Но с современными системами, содержащими 4 ГБ + все же рабочие процессы на 32 бита, это поведение намного менее распространено. Даже самые большие процессы могут получить всю физическую RAM, которую они могут обработать. В тех случаях у них может закончиться память, прежде чем жесткий диск перестанет работать.

Нет никакой общей стратегии обработки, все же. Любой процесс, которому реализовали кэши, должен сбросить их - но хороший кэш был бы уже сброшен, когда ОС сигнализировала о низком условии памяти. Процесс, который отвечает на пользовательские запросы, может обработать bad_alloc при пользовательской гранулярности запроса. Обычно существует мало преимущества в хранении любой выделенной памяти, если у Вас заканчивается память для пользовательского действия. Вместо этого вернитесь к состоянию перед пользовательским действием. Неинтерактивный процесс, с другой стороны, мог бы переключиться на от O (N) к более медленному O (N, регистрируют N), алгоритм.