Travis Vitek wrote:
Martin Sebor wrote:
Farid Zaripov wrote:
Martin Sebor wrote:
...attached is a test case I got from a fellow attendee of my
meeting for what at first blush looks like a COW bug in
stdcxx string. The expected output on line 4 is:
2. cc1: 'H'
21.3.1 p4:
-----------------------------
4 References, pointers, and iterators referring to the elements of a
basic_string sequence may be invalidated by the following uses of
that basic_string object:
- As an argument to non-member functions swap() (21.3.8.8),
operator>>() (21.3.8.9), and getline() (21.3.8.9).
- As an argument to basic_string::swap().
- Calling data() and c_str() member functions.
- Calling non-const member functions, except operator[], at,
begin, rbegin, end, and rend.
- Following construction or any of the above uses, except
the forms of insert and erase that return iterators, the
first call to non-const member functions operator[], at,
begin, rbegin, end, or rend.
-----------------------------
The first call on non-const operator[] for s1 object
located in "s1[0] = 'H';" line. So after that line any
references to the elements are invalidated and cc1
should not be used after that line.
But the spec says:
"...non-const member functions, *except* operator[]..."
So the non-const overload of string::operator[]() is not
allowed to invalidate references.
I think the last bullet is the most important one. It seems to allow for
the first call to op[] to invalidate iterators (and pointers and
references).
Yes, you're right, the last bullet does allow the non-const
operator[] to invalidate references, so the expectation that
the char referred to by cc1 will have any predetermined value
is unfounded. The last but one insertion in the program has
undefined behavior. Thanks for helping me see it!
Travis
Martin
