""Thorsten Ottosen"" <nesotto@cs.auc.dk> wrote in message
news:3faf50cc$0$9606$afc38c87@news.optusnet.com.au...
> "James Kuyper" <kuyper@wizard.net> wrote in message
> news:8b42afac.0311070832.3427e2c2@posting.google.com...
> > dsp@bdal.de (Daniel Spangenberg) wrote in message
[snip]
>
> what is the point of having an exception hierarchy or standard exceptions
if
> implementers are not required to use them?

My point was that this seems like an *error* in the standard because it
makes it really really hard to
make a portable program.

br

Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello, C++ community,

I am wondering, whether I can be sure, that a compliant implementation
of
the std::vector class template gives some throw-guarantees during an
invocation
of  push_back in the following example:

std::vector<T> v;
...
v.push_back(T());

(Note, that I am not asking, whether push_back can destroy the
container, this
is quite clearly specified in the standard)
Assume, that the push_back occurs during near out-of-memory conditions
and assume, that the actions inside push_back finally lead to an
out-of-mem
condition, can I be sure, that push_back throws bad_alloc or a similar
std
exception? Or do I have no such guarantees?

I am a little bit confused, because Josuttis "The C++ Standard Library"
seems
to imply the first in para 6.2.4 "Exception handling"

"[..] In addition the standard requires that only the usual standard
exceptions
may occur, such as bad_alloc for a lack of memory or exceptions of
user-defined
operations"

while my personal interpretation of The current C++98
standard bases on 17.4.4.8 "Restrictions on exception handling"

"Any of the functions defined in the C++ Standard Library can report a
failure by
throwing an exception of the type(s) described in their Throws:
paragraph and/or
their exceptionspecification (15.4). [..]
Any other functions defined in the C++ Standard Library that do not have
an
exceptionspecification may throw implementationdefined exceptions unless

otherwise specified."

with the (non-binding) footnote 178:

"In particular, they can report a failure to allocate storage by
throwing an exception
of type bad_alloc, or a class derived from bad_alloc (18.4.2.1). Library
implementations
are encouraged (but not required) to report errors by throwing
exceptions from (or
derived from) the standard exception classes"

and lead me to the second conclusion. Of course, in the end, the
standard is right,
but maybe I do have a false view on the standard?

The question arose because our current VC7.1 library does not seem to
use any
std exception in this case and it costs us some time to find that out.
("Unusual"
system exceptions are normally caused by programmer errors, so we
couldn't believe
that push_back was the actual reason for it and checked intensively for
different sources)

Thanks for your input,

Daniel Spangenberg




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

dsp@bdal.de (Daniel Spangenberg) wrote in message news:<3FA8AA75.26AEB07B@bdal.de>...
> Hello, C++ community,
>
> I am wondering, whether I can be sure, that a compliant implementation
> of
> the std::vector class template gives some throw-guarantees during an
> invocation
> of  push_back in the following example:
>
> std::vector<T> v;
> ...
> v.push_back(T());
>
> (Note, that I am not asking, whether push_back can destroy the
> container, this
> is quite clearly specified in the standard)
> Assume, that the push_back occurs during near out-of-memory conditions
> and assume, that the actions inside push_back finally lead to an
> out-of-mem
> condition, can I be sure, that push_back throws bad_alloc or a similar
> std
> exception? Or do I have no such guarantees?

The only relevant guarantee you have is in 23.1p10: "if an exception
is thrown by push_back() or push_front(), that function has no
effect."


> I am a little bit confused, because Josuttis "The C++ Standard Library"
> seems
> to imply the first in para 6.2.4 "Exception handling"
>
> "[..] In addition the standard requires that only the usual standard
> exceptions
> may occur, such as bad_alloc for a lack of memory or exceptions of
> user-defined
> operations"
>
> while my personal interpretation of The current C++98
> standard bases on 17.4.4.8 "Restrictions on exception handling"
>
> "Any of the functions defined in the C++ Standard Library can report a
> failure by
> throwing an exception of the type(s) described in their Throws:
> paragraph and/or
> their exceptionspecification (15.4). [..]
> Any other functions defined in the C++ Standard Library that do not have
> an
> exceptionspecification may throw implementationdefined exceptions unless
>
> otherwise specified."
>
> with the (non-binding) footnote 178:
>
> "In particular, they can report a failure to allocate storage by
> throwing an exception
> of type bad_alloc, or a class derived from bad_alloc (18.4.2.1). Library
> implementations
> are encouraged (but not required) to report errors by throwing
> exceptions from (or
> derived from) the standard exception classes"
>
> and lead me to the second conclusion. Of course, in the end, the
> standard is right,
> but maybe I do have a false view on the standard?

No, you have it right.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:8b42afac.0311070832.3427e2c2@posting.google.com...
> dsp@bdal.de (Daniel Spangenberg) wrote in message
news:<3FA8AA75.26AEB07B@bdal.de>...

[snip]
> > I am a little bit confused, because Josuttis "The C++ Standard Library"
> > seems
> > to imply the first in para 6.2.4 "Exception handling"
> >
> > "[..] In addition the standard requires that only the usual standard
> > exceptions
> > may occur, such as bad_alloc for a lack of memory or exceptions of
> > user-defined
> > operations"
> >
> > while my personal interpretation of The current C++98
> > standard bases on 17.4.4.8 "Restrictions on exception handling"
> >
> > "Any of the functions defined in the C++ Standard Library can report a
> > failure by
> > throwing an exception of the type(s) described in their Throws:
> > paragraph and/or
> > their exceptionspecification (15.4). [..]
> > Any other functions defined in the C++ Standard Library that do not have
> > an
> > exceptionspecification may throw implementationdefined exceptions unless
> >
> > otherwise specified."
> >
> > with the (non-binding) footnote 178:
> >
> > "In particular, they can report a failure to allocate storage by
> > throwing an exception
> > of type bad_alloc, or a class derived from bad_alloc (18.4.2.1). Library
> > implementations
> > are encouraged (but not required) to report errors by throwing
> > exceptions from (or
> > derived from) the standard exception classes"
> >
> > and lead me to the second conclusion. Of course, in the end, the
> > standard is right,
> > but maybe I do have a false view on the standard?
>
> No, you have it right.

so this would be legal

push_back( T t )
{
    try
   {
      if( should_grow() )
         grow();
      insert( t );
    }
    catch( ... )
    {
       class Foo { };
       throw Foo();
    }
}

?

what is the point of having an exception hierarchy or standard exceptions if
implementers are not required to use them?

-Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]