🚀 go-pugleaf

In article <316F646D.552DF1DD@cantrip.org> "Nathan Myers
<ncm@cantrip.org>" <ncm@cantrip.org> writes:

|> > Another developer on our team has asked
|> >   How can we be sure that ANSI C++ library callbacks work
|> >   correctly in the face of exceptions?  What if ANSI C++
|> >   library code catches *our* exception?
|> > 
|> > Is this a problem, or are library functions required to reraise any
|> > exceptions thrown by client code?

|> I assume that by "library callbacks" s/he means member functions
|> invoked by library components?

|> Bad things happen if you throw during copy construction or destruction
|> of a vector element.

Does this imply that `vector< string >' is unsafe.  As far as I can
tell, it is impossible to write a conforming basic_string that can
guarantee never to through a `bad_alloc' during copy.  (Even if
basic_string normally uses a shared implementation, the semantic
constraints on pointer validity after reserve would seem to exclude any
sharing of the implementation in this case.  So maybe the restriction
is that you are not allowed to change the size of `vector< string >' if
`reserve' has been called on any of its elements.)

|> Don't let it happen.  (Yes, I know this is easier
|> said than done.  Still.)   There are lots of things in the library that
|> could break if a user object (or even a standard object!) throws during
|> a standard function.  Probably there are some places where it would be
|> safe, but the committee hasn't identified them except in iostreams, where
|> it's specified under what circumstances exceptions are caught and rethrown.

If I understand what you are saying correctly, we should not use
exceptions with the standard library, because it will not be required
to be exception safe.  And just when everyone has been telling me that
I cannot avoid exceptions, because the standard library is throwing
them all over the place.  (And yes, I know.  This latter statement is
just what everyone is saying; in fact, there is almost nowhere in the
standard library where you cannot avoid exceptions if you want to.)
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]