Prev: Is comparison of doubles stable?
Next: What are requirements for allocator destructor?
From: Michael Kilburn on 17 Jul 2010 12:24
Hi,

I have checked C++ standard and did not find requirements imposed on
library implementation with respect to exception safety. But this is
as important of other parts of contract between library and client set
in standard. E.g. if program relies on strong guarantee provided by
some operation and another STL implementation provides only basic --
this program is not C++ program (in a sense that compiled in different
standard-compliant environment it will behave differently).
Did I miss some standard addendum or followup papers? Can someone
point me to right direction, please?

Thanks.
Michael.

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

From: Michael Kilburn on 20 Jul 2010 22:04
On Jul 19, 2:51 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
wrote:
> > > There exist some very general statements and guarantees, see below.
>
> > Yes, I saw them... the problem is that quite often they are not "very
> > general" -- they are incomplete!
>
> If they are incomplete in the sense that the standard is ambiguous
> or contradictory in this regard this would be an issue, yes.

Well, probably my frustration found it's way to the surface -- few
days ago I've spent considerable time trying to figure out what
guarantees vector<string>::resize(10, "AAAA") gives me -- i.e. should
I structure my logic for basic guarantee or strong one (as provided by
my gcc version).
I googled a bit too hoping to find simple and clear list of functions
lined against conditions and guarantees attached to them, but could
not find any :-\

I'll skip most of the quoting and will try to summarize all these
postings -- so you are saying that:
1) unless explicitly specified otherwise any STL operation provides
basic exception guarantee
2) there are no cases on unspecified behaviour other than 3 you
mentioned (exception from dtor, replacement and handler functions)
3) there are places where strong guarantee is guaranteed and mentioned
explicitly

Are those point correct?
What are the "replacement and handler functions" -- functors I pass
into std::transform/etc?

Would be really nice to have a shortlist of cases where STL gives
strong guarantee. Plus readable explanation for undefined behaviour
cases. It is quite painful to extract this infromation from standard
right now. And this, of course, contributes to current state of things
in industry, where 80% of senior level developers do not know what is
going to happen if while throwing exception another exception gets
produced (I did a lot of interviews lately (not as a candidate :-)))
and host of apps that goes bananaz when something goes wrong (like out
of memory).


> Note that clear() now guarantees that it does not throw for any container anyway

Woo-hoo! :-) we definitely need a tight list with explicit description
of exception-related behaviours on a per-function basis in C++
standard. This would serve two important purposes -- library will
become solid and programmers can actually use it as reference.

Thank you.
Michael.


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

From: Mathias Gaunard on 21 Jul 2010 08:25
On Jul 21, 1:47 am, Thomas Richter <t...(a)math.tu-berlin.de> wrote:
> Francis Glassborow wrote:
> >> ??? How should I know how many resources are available? The lack of any
> >> strong guarantee more or less means that proper handling of resource
> >> exhaustion is impossible if you insert more than one element at once.
> >> IOW, all I can do then is to terminate the program? Now, for *that* I
> >> don't need exceptions, do I?
>
> > You are exaggerating. The STL guarantees exception safety. What it does
> > not do is to guarantee the strong version under all circumstances.
>
> Certainly I am, and it was certainly provocative (but for a reason); I
> understand that the STL doesn't provide such a strong guarantee, but
> while I understand some of the reasoning behind, I somehow see that in
> conflict with the principles of the language. I'll come to that later on.
>
> > For example suppose that you try to insert a block of ten elements into
> > a container and that an exception is thrown during this process. You
> > will still have a stable container in a destructable state. However the
> > Standard does not guarantee that it is in the same state that it was
> > prior to your attempt to insert elements.
>
> Certainly, that is understood. But assume that the copy constructors of
> my classes cannot throw (otherwise, of course, I agree that all bets are
> off, and my code is to blame, and not the STL).

Then the only reason the container can throw is because it is out of
memory, which doesn't work reliably on modern operating systems anyway
due to memory overcommit.

Realistically speaking, though, one would expect a good quality
implementation of insert to allocate all the memory needed beforehand
when passed a pair or random access iterators, making the primitive
strongly exception-safe in the lack of user exceptions.


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

From: Goran Pusic on 22 Jul 2010 19:48
On Jul 23, 1:55 am, Thomas Richter <t...(a)math.tu-berlin.de> wrote:
> Mathias Gaunard wrote:
> > Then the only reason the container can throw is because it is out of
> > memory, which doesn't work reliably on modern operating systems anyway
> > due to memory overcommit.
>
> IOW, I cannot use the STL in embedded applications? Or memory
> constrained applications? Not everything is a windows or a Linux.
> Doesn't that conflict with the design principles of C++?

+1 for this.

Also... To my mind, Mathias is wrong from the get-go.

First off, Windows does not overcommit at all. Overcommit is also
optional (albeit prevalent and a default option) on Linux and Unix.

IMO, overcommit should not even be considered as a factor here. To a C+
+ code, it's theoretically equivalent to a power loss. Failures due to
overcommit are (a potential) issue for code running on systems with
overcommit.

Goran.


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

From: Kenneth 'Bessarion' Boyd on 23 Jul 2010 06:46
On Jul 21, 7:47 pm, "Bo Persson" <b...(a)gmb.dk> wrote:

> You DO get an assurance that if anything else throws, like a
> std::bad_alloc, a std::vector will be unchanged.
>
> If your copy constructor or assignment throws, the container will
> fail, but how the heck would you "fix up" the elements that couldn't
> be assigned? How are you going to assign them valid values, when
> assignment throws?

Well, since this is the STL the absence of a strong exception
guarantee for the assignment operator (conditional on strong exception
guarantee, ...) is a noticeable annoyance.

For user containers, that's what would be pragmatic for exception-safe
programming.


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

 |  Next  |  Last
Pages: 1 2
Prev: Is comparison of doubles stable?
Next: What are requirements for allocator destructor?