Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Общие вопросы > Если не хватает памяти на исключение?


Автор: IvanoffAndrey 14.9.2007, 17:09
Согласно Страуструпу, минимум свободной памяти, которая должна быть доступна программе это память необходимая для генерации исключения bad_alloc.
Это значит всего лишь, что насколько я понимаю   bad_alloc (естественно потомок дригих классов) представляет некое подобие статической переменной которую одну и ту же постоянно бросают.
Почему бы, при написании своих исключений (конечно же включенный в общую иерархию), не делать таким образом.
К примеру:

Код

class A{
public:
    static class  error{};//Сам класс исключения.
    static error EXC; // Объект который кидаем.
void METOD(void){
   throw (EXC);
}
}

Я не описал инициализацию переменной EXC нарочно - и так вроде понятно.
[B]Таким образом, поскольку данная статическая  переменная будет инициализировать задолго до создания объекта (размер которого может быть очень большим) а именно на этапе запуска проги (помоему), то память мы уже под исключение зарезервировали и на его бросание хватит места.[B]
Если это не так, то я не знаю каким образом тратися память на бросание исключение кроме как на создание объекта?????
Кто что думает по этому поводу.?
 

Автор: JackYF 14.9.2007, 17:40
Если не хватает памяти даже на исключение, то программе пора убиваться об стену. Ей бессмысленно делать что-либо другое - памяти-то нет.

Автор: zkv 14.9.2007, 17:47
Цитата(JackYF @  14.9.2007,  17:40 Найти цитируемый пост)
Ей бессмысленно делать что-либо другое - памяти-то нет. 

ей можно попробовать память освободить smile

Автор: IvanoffAndrey 14.9.2007, 18:00
Цитата

ей можно попробовать память освободить

Действительно, к примеру скинуть что-нибудь временное  на хард.

Добавлено через 29 секунд
Цитата

то программе пора убиваться об стену

 smile 

Автор: Mayk 14.9.2007, 18:45
Цитата(IvanoffAndrey @  14.9.2007,  21:09 Найти цитируемый пост)
Кто что думает по этому поводу.?

Не то Александрески, не то Саттер, не то они оба, но есть слухи что в современных условиях на PC проверять успешность выделения памяти бессмыссленно. Вот что по этому поводу говорит malloc(3)
Цитата

BUGS
       By  default,  Linux  follows an optimistic memory allocation strategy.  This means
       that when malloc() returns non-NULL there is no guarantee that the  memory  really
       is  available.  This is a really bad bug.  In case it turns out that the system is
       out of memory, one or more processes will be killed by the  infamous  OOM  killer.


Добавлено через 27 секунд
Короче, если программе не хватает памяти, то она об этом попросту может никогда не узнать.

Автор: JackYF 14.9.2007, 20:32
Цитата(zkv @  14.9.2007,  17:47 Найти цитируемый пост)
ей можно попробовать память освободить smile

предполагались, что эти попытки уже были сделаны smile


Цитата(Mayk @  14.9.2007,  18:45 Найти цитируемый пост)
optimistic memory allocation strategy

гыгык smile класс

Автор: Mihhail 14.9.2007, 21:21
Цитата(IvanoffAndrey @  14.9.2007,  17:09 Найти цитируемый пост)
Согласно Страуструпу, минимум свободной памяти, которая должна быть доступна программе это память необходимая для генерации исключения bad_alloc.
.....................
.....................
Таким образом, поскольку данная статическая  переменная будет инициализировать задолго до создания объекта (размер которого может быть очень большим) а именно на этапе запуска проги (помоему), то память мы уже под исключение зарезервировали и на его бросание хватит места.

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

А такой случай: Загружена одна программа, начинает загружаться вторая, из-за нехватки памяти первая скидавается на хард и этим он забивается под завязку. А вторая при этом полностью занимает память. Первая - заблокирована до окончания работы второй.!?
Теоретика однако.... smile 

Автор: UnrealMan 15.9.2007, 11:15
Цитата(IvanoffAndrey @  14.9.2007,  18:09 Найти цитируемый пост)
Почему бы, при написании своих исключений (конечно же включенный в общую иерархию), не делать таким образом.

В C++ одновременно может существовать несколько неперехваченных исключений (в том числе одного типа).

Автор: Любитель 15.9.2007, 13:01
Цитата(Mayk @  14.9.2007,  18:45 Найти цитируемый пост)
Не то Александрески, не то Саттер, не то они оба, но есть слухи что в современных условиях на PC проверять успешность выделения памяти бессмыссленно.

У первого не помню (его всё же больше всякие изящества интересуют smile ), а вот у второго было точно, притом достаточно подробно всё объяснялось - где, зачем и почему. Автору советую прочитать smile

Автор: IvanoffAndrey 15.9.2007, 20:02
Плиз скинте название книги. Я очень люблю всякие книжки читать. Но об том авторе ничего прежде не слышал. Как понимаю это все еще классика?

Добавлено через 7 минут и 21 секунду
Цитата

В C++ одновременно может существовать несколько неперехваченных исключений (в том числе одного типа). 

Насколько я помню больше одного исключения (может больше двух) С++ не может обработать вообще и в этой ситуации просто грубо завершает программу?.

Автор: UnrealMan 15.9.2007, 21:56
Цитата(IvanoffAndrey @  15.9.2007,  21:02 Найти цитируемый пост)
Насколько я помню больше одного исключения (может больше двух) С++ не может обработать вообще и в этой ситуации просто грубо завершает программу?. 

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

Автор: Любитель 16.9.2007, 13:49
Цитата(IvanoffAndrey @  15.9.2007,  20:02 Найти цитируемый пост)
Плиз скинте название книги. Я очень люблю всякие книжки читать. Но об том авторе ничего прежде не слышал. Как понимаю это все еще классика?

Саттер: "Сложные задачи по C++" и (новее и интереснеее) "Новые сложные задачи по C++". Да - классика, но не совсем тривиальная.

Автор: IvanoffAndrey 16.9.2007, 16:08
А что за книга у Александрески?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)