If I understand correctly, the std::vector functions that can allocate
memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception being
throw if insufficient memory is available.   Would someone kindly confirm
this is true?

Thanks for your time.

Ian



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On 25 Nov 2004 03:57:30 -0500, "Ian" <ibnospam@yahoo.com> wrote:

 >If I understand correctly, the std::vector functions that can allocate
 >memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception being
 >throw if insufficient memory is available.   Would someone kindly confirm
 >this is true?

Yes, but note that they can also throw other exceptions, depending on
the implementation. They can also throw any exceptions thrown by the
constructors of the value_type.

You may find this useful:
http://www.research.att.com/~bs/3rd_safe0.html

Tom

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ian" <ibnospam@yahoo.com> wrote in message
 > If I understand correctly, the std::vector functions that can allocate
 > memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception
being
 > throw if insufficient memory is available.   Would someone kindly confirm
 > this is true?

An exception could be thrown but Standard promises that std::vector<T,
A>::push_back() always either succeeds or has no effect.
23.1/10 - "if an exception is thrown by a push_back() or push_front()
function, that function has no effects."

23.2.4.2/6 -
void resize(size_type sz, T c = T());

Effects:
if (sz > size())
insert(end(), sz-size(), c);
else if (sz < size())
erase(begin()+sz, end());
else
; //do nothing

Later Standard says the following for vector's insert -
23.2.4.3/1 - "If an exception is thrown other than by the copy constructor
or assignment operator of T there are no effects." and for erase
(23.2.4.3/5)  - "Throws: Nothing unless an exception is thrown by the copy
constructor or assignment operator of T."

Sharad



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ian" <ibnospam@yahoo.com> wrote in message
news:jG6pd.68855$3u6.2052929@wagner.videotron.net...
| If I understand correctly, the std::vector functions that can allocate
| memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception being
| throw if insufficient memory is available.   Would someone kindly confirm
| this is true?

that is true.

note, however, that the library is free to throw a different error (although I
can't think of why somebody would do that)

-Thorsten



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi,

Ian wrote:
 > If I understand correctly, the std::vector functions that can allocate
 > memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception being
 > throw if insufficient memory is available.   Would someone kindly confirm
 > this is true?

This is true.
The bad_alloc exception may be thrown by the default allocator, which is
normally used by std::vector.

I think that it is legal to roll up your own allocator that manifests
its failures in other ways, if for any reason bad_alloc is bad.

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ian" <ibnospam@yahoo.com> wrote in message
news:<jG6pd.68855$3u6.2052929@wagner.videotron.net>...
> If I understand correctly, the std::vector functions that can allocate
> memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception being
> throw if insufficient memory is available.   Would someone kindly confirm
> this is true?

Yes - it _can_ throw std::bad_alloc according to the standard. However,
they might throw another exception instead. bad_alloc in encouraged
but not mandatory -see footnote 181.

Regards,
Michiel Salters

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Ian" <ibnospam@yahoo.com> skrev i meddelandet 
news:jG6pd.68855$3u6.2052929@wagner.videotron.net...
> If I understand correctly, the std::vector functions that can allocate
> memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception 
> being
> throw if insufficient memory is available.   Would someone kindly 
> confirm
> this is true?

Yes.

If you resize to something that is larger than the vector's capacity(), 
it must allocate more memory. If that fails, you will most probably see 
a bad_alloc.


Bo Persson 



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi Ian,

> If I understand correctly, the std::vector functions that can allocate
> memory (e.g. resize,  push_back) can lead to the 'bad_alloc' exception being
Actually everything comes to inserting new elements, for example (quote 
from SGI STL implementation):

void resize(size_type __new_size, bool __x = bool()) {
     if (__new_size < size())
       erase(begin() + difference_type(__new_size), end());
     else
       insert(end(), __new_size - size(), __x);
}
> throw if insufficient memory is available.   Would someone kindly confirm
> this is true?
> 
To 'split' algorithms and containers implementation from "memory" 
handling details STL uses allocators. And since everything that behaves 
like allocator is considered to be one, throwing or not exception will 
depend on the allocator implementation.
For example:

std::vector<int> v; //will use default (standard) allocator, that will 
rely on:

void* operator new(size_t) throw(bad_alloc)

so in case of available memory being exhausted bad_alloc will be thrown.

However one can provide custom allocator, like:

std::vector<int, My_Alloc<int> > v; which implementation may rely upon:

void* operator new(size_t, const nothrow_t& ) throw();

As you can see, in this case no bad_alloc will be thrown.

Hope this one helps,

Best regards,
  Stanimir Kabaivanov

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Maciej Sobczak <no.spam@no.spam.com> wrote in message
news:<41a5a24f$1_1@news.bluewin.ch>...

> Ian wrote:
>  > If I understand correctly, the std::vector functions that can
>  > allocate memory (e.g. resize, push_back) can lead to the
>  > 'bad_alloc' exception being throw if insufficient memory is
>  > available. Would someone kindly confirm this is true?

> This is true.
> The bad_alloc exception may be thrown by the default allocator, which
> is normally used by std::vector.

> I think that it is legal to roll up your own allocator that manifests
> its failures in other ways, if for any reason bad_alloc is bad.

I'm not sure what the standard says about this (and I'm too lazy to look
it up), but if your own allocator manifests its failures by any means
other than an exception, I doubt that std::vector will work correctly.
(This is just common sense, really.  I mean, can you conceive of any
possible way to write generic code which will correctly handle
insufficient memory without knowing how the error condition will be
reported?)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

kanze@gabi-soft.fr wrote:

>>I think that it is legal to roll up your own allocator that manifests
>>its failures in other ways, if for any reason bad_alloc is bad.

> I'm not sure what the standard says about this (and I'm too lazy to look
> it up), but if your own allocator manifests its failures by any means
> other than an exception, I doubt that std::vector will work correctly.
> (This is just common sense, really.  I mean, can you conceive of any
> possible way to write generic code which will correctly handle
> insufficient memory without knowing how the error condition will be
> reported?)

If for any reason exceptions are banned, then a viable solution (YMMV, 
of course) may be to terminate right in the allocator, possibly after 
leaving some info in the outside world about the cause (sending mail to 
operator, writing to a log file, blinking a big red LED on the front 
panel, etc.).

I find this option to be much more well-behaved than, for example, being 
struck immediately by a signal from OS, without any chance to say good 
bye. I suppose that some platforms do just that.

I also think that it would be legal to throw something else than 
bad_alloc from the allocator (I thought the question was about 
bad_alloc, not about exceptions in general). If, for any reason, the 
standard exception hierarchy is considered awful and the project 
policies impose other exception types, then it should be OK to write 
allocator that throws OurMickeyMouseException instead of bad_alloc.
This is a moot point, however - such projects are usually very 
consistent in this kind of policies and impose also 
OurMickeyMouseContainer instead of std::vector. ;)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]