Re: Exception-safety of erase
From the C++ Standard (point 23.1 Container requirements
[lib.container.requirements] $10) we now that "erase" on a conta
iner
will never throw an exception. Copy constructor or assignment
operator
of an iterator returned from a container does not throw any
exceptions
as well.
Those are requirements on the specific containers defined in the
standard, not on Containers in general (objects satisfying the
"Container" concept -- see table 65).
Yes. Indeed. I somehow missed the description before the list of
requirements in point $10 of 23.1.
But "erase" specification (23.1.1 Sequences [lib.sequence.reqmts])
does not require it to take as an argument iterator returned by the
container.
You're comparing apples and oranges here. The sequence
requirements are
a concept. They only describe a subset of the requirements
satisfied by
the standard containers. If you look at the synopses of the
individual
containers you'll see that erase(...) always takes an iterator.
(...)
Thous actually calling "gerase" might result in an exception alth
ough
in that case the execution will never get into erase.
True in general, but not for the specific containers defined in the
standard library.
Yes for the second time. The funny thing is - believe it or not! -
I read that part of the Standard many times (now and then) so in fact
I knew it. But yet I somehow managed to magically forget it and wrote
that desperate post. :)
But this opens another question. This time regarding iterators
(possibly those passed to "erase" ? so we do not fall off topic
here :)).
In the Standard in point 23.1 $10 in the forth point we can read:
"no copy constructor or assignment operator of a returned iterator
throws an exception.". Fine. But there is no definition of what is
named a "returned iterator".
Are those the container's member types "iterator" and
"const_iterator" (and maybe revers iterators as well when they
exist?). It would be nice and logical. But on the other hand why
wouldn't the Standard say just "iterator" (and those other iterators -
maybe a common term could be introduced here) instead of the cryptic
(IMHO) "returned iterator"?
Note that it is not obvious (again IMHO) that the Standard meant
here any iterators not just those instances returned by container
functions. I don't see any reason to think that the Standard just used
a strange name. And although copy constructor and assignment operator
belong to iterator's type and not particular instance their behavior
naturally depends on that particular instance. And thous the non-
throwing guarantee may depend on the instance as well. And if so, then
following code:
container::iterator it1;
container::iterator it2 = it1;
might result in an exception in initialization of i2 since i1 is not
returned from a container (if the "returned iterator" is to be
understood literally).
(Actually it might throw exception in default construction of it1
as well since there is no guarantee of non-throwing default
constructor of container's iterator type ? or is it a general iterator
requirement? Or I again missed something?)
Adam Badura
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]