Re: [boost] [iterator] reverse_iterator<counting_iterator<T>>
"Stewart, Robert" <Robert.Stewart@sig.com <mailto:Robert.Stewart@sig.com> > wrote in message news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com <news:DF2E67F3D097004694C8428C70A3FD690470B26B7F@msgbal516.ds.susq.com> ...
this->base() calls iterator_adaptor<>::base(), which returns a reference to the underlying iterator it holds. Passing that reference to boost::prior() means that prior() pre-decrements the iterator within the iterator_adaptor. It would be odd for that
decrement operator to return anything but a reference to the decremented object, so boost::prior() returns a reference to its decremented argument, a reference to the decremented iterator within the iterator_adaptor.
I see no problem.
boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it. I overlooked that I already filed a defect a while ago for it: https://svn.boost.org/trac/boost/ticket/2640 <https://svn.boost.org/trac/boost/ticket/2640> It would be great to have it fixed, because the bug is quite subtle and may go undetected for a while. Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229
Arno Schödl wrote:
"Stewart, Robert" <Robert.Stewart@sig.com
this->base() calls iterator_adaptor<>::base(), which returns a reference to the underlying iterator it holds. Passing that reference to boost::prior() means that prior() pre-decrements the iterator within the iterator_adaptor. It would be odd for that
decrement operator to return anything but a reference to the decremented object, so boost::prior() returns a reference to its decremented argument, a reference to the decremented iterator within the iterator_adaptor.
I see no problem.
boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it.
boost::prior's T is deduced as a reference type. The copy is of a reference. There's no temporary. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Arno Schödl wrote:
"Stewart, Robert" <Robert.Stewart@sig.com boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it.
boost::prior's T is deduced as a reference type. The copy is of a reference. There's no temporary.
You can think of the code as doing the equivalent of the following: reference dereference() const { counting_iterator<T> temp_it = this->base(); // holds a T value --temp_it; return *temp_it; // return a reference to a member object of temp_it --> BAD } (Note: I changed "constant_iterator" to "counting_iterator", but the bug exists regardless.) The change suggested by Arno (counting_iterator should return by value upon dereferencing unless the T member object is held by reference) seems like a good one. - Jeff
Jeffrey Hellrung wrote:
Stewart, Robert wrote:
Arno Schödl wrote:
"Stewart, Robert" <Robert.Stewart@sig.com
boost::prior(...) internally makes a copy of its iterator argument, decrements it and returns it by value, so far so good. counting_iterator::operator* then returns a reference into this (temporary) iterator. Returning from reverse_iterator::dereference() destroys the temporary iterator, but still returns the reference pointing into it.
boost::prior's T is deduced as a reference type. The copy is of a reference. There's no temporary.
You can think of the code as doing the equivalent of the following:
reference dereference() const { counting_iterator<T> temp_it = this->base(); // holds a T value --temp_it; return *temp_it; // return a reference to a member object of temp_it --> BAD }
Taking another look: reference dereference() const { return *boost::prior(this->base()); } this->base() is: Base const & base() const { return m_iterator; } That returns Iterator const &, which is passed to boost::prior(), which is: template <class T> T prior(T x) { return --x; } If T is deduced as Iterator const &, x is a reference, which was my earlier inference, but operator --(), which is non-const, would be applied to that reference to const and wouldn't compile. That's the detail I missed earlier. Clearly, the compiler deduces T as Iterator, copy constructs a temporary Iterator from the reference returned by this->base(), and then decrements that temporary. That leads to the OP's concern and you see that I'm finally on board. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
The change suggested by Arno (counting_iterator should return by value upon dereferencing unless the T member object is held by reference) seems like a good one.
constant_iterator<T>::reference could be defined as T, but operator* could return T const&. I am not sure if this fulfills the Iterator requirements in the standard, but it would avoid a copy when trivially calling it->func(), while still making reverse_iterator work as expected. Arno -- Dr. Arno Schoedl · aschoedl@think-cell.com Technical Director think-cell Software GmbH · Chausseestr. 8/E · 10115 Berlin, Germany http://www.think-cell.com · phone +49 30 666473-10 · toll-free (US) +1 800 891 8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Berlin-Charlottenburg, HRB 85229
participants (3)
-
Arno Schödl -
Jeffrey Hellrung -
Stewart, Robert