[RFC] std::string(0);

Dhruv Matani dhruvbird@gmx.net
Mon Jun 14 15:17:00 GMT 2004


On Mon, 2004-06-14 at 13:50, Jonathan Wakely wrote:
> On Sat, Jun 12, 2004 at 09:13:48AM +0530, Dhruv Matani wrote:
> 
> > Actually, when I started learning about the STL about a year ago, I read
> > in TC++PL, that end() for a container stood for *one past the last*
> > valid iterator in a container.
> 
> Technically, end() is valid, but it is not dereferenceable
> (a "valid" iterator is defined as one that is dereferenceable *or*
> past-the-end)
> 
> So a better definition would be "one past the last dereferenceable
> iterator" 

Ok, that explains it. All this while I was wondering how Stroustrup
could write such a thing! The mystery is solved! It was my fault all
along. I kept thinking of the last valid iterator as the one that
contained/pointed to a valid element.

> 
> >                                So, when I applied it to an empty
> > container, I was horribly confused!. This meant that an empty container
> > and a container with only one element should have the same internal
> > representation!, because end() was one *past* the last, so end() should
> > be reachable from begin() after incrementing begin() at least once.
> 
> Your reasoning assumes that begin() for an empty container is a
> dereferenceable iterator - but it isn't, it's past-the-end, and so
> [begin,end()) is an empty range.
> 
> There's no double definition is you think in terms of dereferenceable
> and past-the-end, and remember that "valid" includes past-the-end.

Yes, thanks for the explanation! This does clear some doubt in my mind!

I must remember that end() is a valid iterator though it may not be
derefrenceable.

However, that brings another thing to my mind. I have seen at many
places stuff like this:

&*end();

So, would the above be valid?




-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html




More information about the Libstdc++ mailing list