Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.188.168.28] |
|
Сообщ.
#1
,
|
|
|
Тут у меня вопрос возник. Интересный до безобразия.
Возьмем обычный std::vector. У него (и не только у него) есть метод push_back - добавление элемента в конец. Что происходит, если память выделить под новый элемент не удалось? вот например описание http://msdn.microsoft.com/library/default....orpush_back.asp здесь вопрос, что происходит если выделить память не удалось - мягко обойден. И все что происходит в случае, если выделить память не удалось? отлавливать try catch-ем? не хочу. (кстати.. а может и хочу, надо подумать) Проверять: изменился ли размер vector-а? не очень то красиво. |
Сообщ.
#2
,
|
|
|
ну напиши пример с бесконечным выделением и посмотри. делов-то...
|
Сообщ.
#3
,
|
|
|
а когда это произойдет (что память не выделится)?
надо всю оперативу схавать + подкачка......... меня одно время тоже интересовал вопрос: при работе с каллок\маллок в умных книжках написано, что нужно проверять возвращенную память на предмет выделилась ли она! Однако на практике я никогда это не делал - т.к. не видел смылса проверять выделилось ли 1024 байта (допустим).... |
Сообщ.
#4
,
|
|
|
Будет сгенерировано исключение bad_alloc. Ты можешь либо перехватить его, либо нет. Если нет - тогда произойдет аварийное завершение проги. Так что проверить размер vector'а тебе никто не даст.
Правда можно перегрузить глобальный оператор new и переписать соотвествующим образом сам vector и распределитель памяти allocator... Так что лучше уж IMHO перехватывать bad_alloc. |
Сообщ.
#5
,
|
|
|
то бишь нужно сделать примерно вот так:
try { myvector.push_back(100); } catch(bad_alloc ba) { //тут что то сделать? } ? |
Сообщ.
#6
,
|
|
|
Ну, вообще говоря - да.
ЗЫ: См. раздел стандарта 20.4.1.1, пункт 7. |
Сообщ.
#7
,
|
|
|
хоккей. гляну в стандарт.
|
Сообщ.
#8
,
|
|
|
Значит так - расскажу как было.
Судя по Стандарту, bad_alloc генерируется в случае, когда с памятью совсем все хреново. Это хорошо. Но вот пример небольшой програмки, которая (ИМХО) тоже должна вызывать исключение. Но до меня это исключение не доходит, а видимо отлавливается системой. програмка: vector <int> nData; try { nData.resize(100000000); } catch(bad_alloc ) { printf("bad alloactor!"); } сообщение: "Out of memory!" То есть - система значительно раньше отлавливает попытку выделить больше, чем можно. Это можно как то отловить? Или же придется всегда смотреть за наличаем свободной памяти в системе? Спасибо за внимание |
Сообщ.
#9
,
|
|
|
А что за система.
|
Сообщ.
#10
,
|
|
|
WinXP. на 2000 проверял - тоже самое. К другим доступа нет.
|
Сообщ.
#11
,
|
|
|
В общем - рассказываю в чём было дело.
Наверняка кому нибудь понадобится. Во первых, все эти bad_alloc-и нужно было вылавливать после следующей операции: #include <new.h> #include <new> using namespace std; int _cdecl my_new_handler(size_t) { throw bad_alloc(); return 0; } _PNH _old_new_handler; _old_new_handler = _set_new_handler(my_new_handler); ..//тут вся ботва с try catch - в этом случае bad_alloc будет генерироваться try { } catch(bad_alloc &ba)//стандарт не гарантирует появления копии bad_alloc-а //поэтому ловить его нужно по ссылке { //сделать что нибудь } _set_new_handler(_old_new_handler); Вот. Это во первых. А во вторых - мессаго Out of memory вываливалась при использовании MFC(!) При чем в любом случае. Кстати, в этом случае такая перегрузка не поможет. Вывод: используете MFC - ловите только MFC-шные исключения Другие скорее всего не придут. (даже bad_alloc!) (вечно у дяди Билли со стандартами напряженка). Кстати - интересно. В многопоточном приложении перегрузку _set_new_handler достаточно один раз сделать? |