reverse_iterator::base, possible bug?

[Eric Twietmeyer]

Hello,

In playing with a reverse_iterator issue today, I realized that I could use
its base() method to get at the underlying iterator. However, I realized
that in the implementation shipping with VC7.1 the base() method returns
"current", the internal iterator object, but that "current" iterator is
always set up to be "pointing" at the element AFTER the one you think.

For instance in <xutility> operator*() is defined as:

reference operator*() const
{
_RanIt _Tmp = current;
return *--_Tmp;
}

So if one uses the base() method you get something unexpected, i.e. you get
"current", which must be decremented before dereferenced to get the element
value you want.

At least, it seems unexpected if one reads section 16.3.2 of Stroustrup C++
3rd Ed. (page 445 in soft cover version). There he has an example of a
find_last method that reads:

template <class C>
typename C::iterator find_last( const C& c, typename C::value_type v )
{
return find_first( c.rbegin(), c.rend(), v ).base();
}

which seems to imply that base() should return the iterator to the element
found by find_first, not the one after the element found.

Basically, the question is: Is the shipping implementation correct? I
assume it is, but then I don't understand how the example from Stroustrup is
supposed to work.

Thanks,

-Eric Twietmeyer

[Doug Harrison [MVP]]

Eric Twietmeyer wrote:

Hello,

In playing with a reverse_iterator issue today, I realized that I could use
its base() method to get at the underlying iterator. However, I realized
that in the implementation shipping with VC7.1 the base() method returns
"current", the internal iterator object, but that "current" iterator is
always set up to be "pointing" at the element AFTER the one you think.

For instance in <xutility> operator*() is defined as:

reference operator*() const
{
_RanIt _Tmp = current;
return *--_Tmp;
}

So if one uses the base() method you get something unexpected, i.e. you get
"current", which must be decremented before dereferenced to get the element
value you want.
That's the way reverse_iterator::base is supposed to work.
At least, it seems unexpected if one reads section 16.3.2 of Stroustrup C++
3rd Ed. (page 445 in soft cover version). There he has an example of a
find_last method that reads:

template <class C>
typename C::iterator find_last( const C& c, typename C::value_type v )
{
return find_first( c.rbegin(), c.rend(), v ).base();
}

which seems to imply that base() should return the iterator to the element
found by find_first, not the one after the element found.

Basically, the question is: Is the shipping implementation correct? I
assume it is, but then I don't understand how the example from Stroustrup is
supposed to work.

That was fixed in an erratum:

Errata for 5th printing of The C++ Programming Language
http://www.research.att.com/~bs/3rd_printing6.html

--
Doug Harrison
Microsoft MVP - Visual C++

[Eric Twietmeyer]

"Doug Harrison [MVP]" <ds*@mvps.org> wrote in message
news:1j********************************@4ax.com...

<snip>

That was fixed in an erratum:

Errata for 5th printing of The C++ Programming Language
http://www.research.att.com/~bs/3rd_printing6.html
Thanks for the pointer! I was quite confused by this. I'll try to look in
the
standard and see what it says about "base". Thanks again.

--
Doug Harrison
Microsoft MVP - Visual C++

-Eric Twietmeyer

[Carl Daniel [VC++ MVP]]

Eric Twietmeyer wrote:

Thanks for the pointer! I was quite confused by this. I'll try to
look in the
standard and see what it says about "base". Thanks again.

Also look in Scott Meyer's "Effective STL" for a lengthy discussion of the
bizzare behavior of reverse_iterator.

-cd