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

Q>>Как раз bad_alloc не показатель, что памяти нет и все караул.
Q>>Если запросить большой непрерывный блок, то из-за фрагментации адресного пространства можно получить bad_alloc и при наличии свободных гигабайтов.
K>Ты такое встречал хоть раз не на велосипедных аллокаторах которые не умеют такое обрабатывать?

Конечно, встречал.

std::vector<int> v(10000000, 0);

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

Q>>Просто не нашлось непрерывного куска в 200 мб...
K>Отлично, отлично... а теперь придумай что в этом случае делать? Вот надо что-то сделать же, да? Вот напиши 3 вариант кроме падения с терминейтом.

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

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

А может просто пользователь начудил и задал какие-то огромные значения входных параметров, программа ему говорит "не шмогла", а он такой — ну и ладно, задам параметры поменьше.

Непонятно, зачем именно bad_alloc так демонизировать, что сразу в терминейт...