bad_alloc

[George2]

Hello everyone,


Please help to comment whether my following understanding is correct,

1. whether or not we are using auto_ptr to allocate new object on heap
(using new), there may be bad_alloc exceptions;

2. when we met with such exceptions, we catch it (bad_alloc) and try
to mininize the operation in catch handler block (since when bad_alloc
occurs, it means memory is running out, we can not do anything complex
in handler).

Both are correct? Please feel free to correct me if I am wrong.


thanks in advance,
George

 

[Daniel T.]

Please help to comment whether my following understanding is correct,

1. whether or not we are using auto_ptr to allocate new object on heap
(using new), there may be bad_alloc exceptions;

Right. Any time *any* code uses 'new' a bad_alloc exception may result.
This includes vector::reserve() and vector:ush_back() for example.

2. when we met with such exceptions, we catch it (bad_alloc) and try
to mininize the operation in catch handler block (since when bad_alloc
occurs, it means memory is running out, we can not do anything complex
in handler).

When a bad_alloc occurs, it means the allocation in question has failed.
It all depends on how big that allocation attempt was as to whether
"memory is running out" or not.

Catching a bad_alloc is only useful if you have a situation where there
are two ways of doing something, one is fast but requires lots of
memory, while the other way is slow and requires little memory. You can
attempt to grab the memory, if the attempt succeeds you can do it the
fast way. If the attempt fails, you will have to do the job using the
slow method.

 

[Erik Wikström]

Hello everyone,


Please help to comment whether my following understanding is correct,

1. whether or not we are using auto_ptr to allocate new object on heap
(using new), there may be bad_alloc exceptions;
Yes.

2. when we met with such exceptions, we catch it (bad_alloc) and try
to mininize the operation in catch handler block (since when bad_alloc
occurs, it means memory is running out, we can not do anything complex
in handler).

That is an over generalisation. If, for example, you tried to create a
new instance of a Foo object and they use a specialised pool-allocator
it might throw a bad_alloc when to pool is all used up. But that does
not have to mean that you do not have plenty of memory left for objects
that do not use the pool allocator.

Also, you might have lots of free memory for objects with automatic
storage even though you have used up the free store, which means that
you can create lots of new objects as long as you do not use new.

 

[Duane Hebert]

Hello everyone,


Please help to comment whether my following understanding is correct,

1. whether or not we are using auto_ptr to allocate new object on heap
(using new), there may be bad_alloc exceptions;

Not sure what auto_prt has to do with bad_alloc except that it should
take care of cleanup of its internals when an exception occurs in
its construction.

2. when we met with such exceptions, we catch it (bad_alloc) and try
to mininize the operation in catch handler block (since when bad_alloc
occurs, it means memory is running out, we can not do anything complex
in handler).

Both are correct? Please feel free to correct me if I am wrong.

Not sure what you're saying here either. If you use an auto_ptr, what
would you do in the catch block? Issue an error to the caller maybe?
You generally use smart pointers to handle the cleanup for you.

One thing to note is that bad_alloc doesn't happen ONLY when you're
out of memory. It can also happen when you need to allocate contiguous
memory and there isn't enough - say for a std::vector. Not exactly the same
thing
as you may have lots of memory but it may be all fragmented.