Re: Andrei's "iterators must go" presentation
Hakusa@gmail.com (Hakusa) wrote (abridged):
I see. Then, if you are correct, container.end()++ may work in some
cases as expected (string, vector, etc) but you are saying that not
only will dereferencing it be undefined, but what happens to the
iterator itself is undefined? And if so, that I could not rely on
the assumption c.end() < ++c.end()?
Suppose, for example, we have a std::vector<char> whose data just happens
to be allocated at the top of memory, so end() returns a pointer with
value 0xffff ffff. Then incrementing that gives 0x0000 0000, which is not
greater than end().
More likely is that the vector's data gets allocated into its own memory
block which comes directly from the operating system. The allocator might
do that if the block is large. Then the address end()+1 can point after
that block, into memory that the application does not have the right to
access. The CPU can check access rights when the pointer is loaded into a
register, so you can get an access error without even dereferencing it.
(I've seen this happen. It was a pain to debug, because the DEBUG version
of the library was adding sentinel bytes which prevents the situation
from occurring.)
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]