This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
reverse_iterator::operator->
should also support smart pointersSection: 24.5.1.6 [reverse.iter.elem] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2021-06-06
Priority: Not Prioritized
View all other issues in [reverse.iter.elem].
View all issues with Resolved status.
Duplicate of: 2775
Discussion:
Addresses UK 281 [CD1]
The current specification for return value for reverse_iterator::operator->
will always be a true pointer type, but reverse_iterator
supports proxy
iterators where the pointer type may be some kind of 'smart pointer'.
[ Summit: ]
move_iterator
avoids this problem by returning a value of the wrapped Iterator type. study group formed to come up with a suggested resolution.
move_iterator
solution shown in proposed wording.
[ 2009-07 post-Frankfurt: ]
Howard to deconceptize. Move to Review after that happens.
[ 2009-08-01 Howard deconceptized: ]
[ 2009-10 Santa Cruz: ]
We can't think of any reason we can't just define reverse iterator's pointer types to be the same as the underlying iterator's pointer type, and get it by calling the right arrow directly.
Here is the proposed wording that was replaced:
template <class Iterator> class reverse_iterator { […] typedeftypename iterator_traits<Iterator>::pointerpointer;Change [reverse.iter.opref]:
pointer operator->() const;Returns:
&(operator*());this->tmp = current; --this->tmp; return this->tmp;
[ 2010-03-03 Daniel opens: ]
- There is a minor problem with the exposition-only declaration of the private member
deref_tmp
which is modified in a const member function (and the same problem occurs in the specification ofoperator*
). The fix is to make it a mutable member.The more severe problem is that the resolution for some reasons does not explain in the rationale why it was decided to differ from the suggested fix (using
deref_tmp
instead oftmp
) in the [ 2009-10 Santa Cruz] comment:this->deref_tmp = current; --this->deref_tmp; return this->deref_tmp;combined with the change of
typedef typename iterator_traits<Iterator>::pointer pointer;to
typedef Iterator pointer;The problem of the agreed on wording is that the following rather typical example, that compiled with the wording before 1052 had been applied, won't compile anymore:
#include <iterator> #include <utility> int main() { typedef std::pair<int, double> P; P op; std::reverse_iterator<P*> ri(&op + 1); ri->first; // Error }Comeau online returns (if a correspondingly changed
reverse_iterator
is used):"error: expression must have class type return deref_tmp.operator->(); ^ detected during instantiation of "Iterator reverse_iterator<Iterator>::operator->() const [with Iterator=std::pair<int, double> *]""Thus the change will break valid, existing code based on
std::reverse_iterator
.IMO the suggestion proposed in the comment is a necessary fix, which harmonizes with the similar specification of
std::move_iterator
and properly reflects the recursive nature of the evaluation ofoperator->
overloads.Suggested resolution:
In the class template
reverse_iterator
synopsis of 24.5.1.2 [reverse.iterator] change as indicated:namespace std { template <class Iterator> class reverse_iterator : public iterator<typename iterator_traits<Iterator>::iterator_category, typename iterator_traits<Iterator>::value_type, typename iterator_traits<Iterator>::difference_type,typename iterator_traits<Iterator>::pointer, typename iterator_traits<Iterator>::reference> { public: [..] typedeftypename iterator_traits<Iterator>::pointerpointer; [..] protected: Iterator current; private: mutable Iterator deref_tmp; // exposition only };- Change [reverse.iter.opref]/1 as indicated:
pointer operator->() const;1
ReturnsEffects:&(operator*())
.deref_tmp = current; --deref_tmp; return deref_tmp;
[ 2010 Pittsburgh: ]
We prefer to make to use a local variable instead of
deref_tmp
withinoperator->()
. And although this means that themutable
change is no longer needed, we prefer to keep it because it is needed foroperator*()
anyway.Here is the proposed wording that was replaced:
Change [reverse.iter.opref]:
pointer operator->() const;Returns:
&(operator*());deref_tmp = current; --deref_tmp; return deref_tmp::operator->();
[ 2010-03-10 Howard adds: ]
Here are three tests that the current proposed wording passes, and no other solution I've seen passes all three:
Proxy pointer support:
#include <iterator> #include <cassert> struct X { int m; }; X x; struct IterX { typedef std::bidirectional_iterator_tag iterator_category; typedef X& reference; struct pointer { pointer(X& v) : value(v) {} X& value; X* operator->() const {return &value;} }; typedef std::ptrdiff_t difference_type; typedef X value_type; // additional iterator requirements not important for this issue reference operator*() const { return x; } pointer operator->() const { return pointer(x); } IterX& operator--() {return *this;} }; int main() { std::reverse_iterator<IterX> ix; assert(&ix->m == &(*ix).m); }Raw pointer support:
#include <iterator> #include <utility> int main() { typedef std::pair<int, double> P; P op; std::reverse_iterator<P*> ri(&op + 1); ri->first; // Error }Caching iterator support:
#include <iterator> #include <cassert> struct X { int m; }; struct IterX { typedef std::bidirectional_iterator_tag iterator_category; typedef X& reference; typedef X* pointer; typedef std::ptrdiff_t difference_type; typedef X value_type; // additional iterator requirements not important for this issue reference operator*() const { return value; } pointer operator->() const { return &value; } IterX& operator--() {return *this;} private: mutable X value; }; int main() { std::reverse_iterator<IterX> ix; assert(&ix->m == &(*ix).m); }
[ 2010 Pittsburgh: ]
Moved to NAD Future, rationale added.
[LEWG Kona 2017]
Recommend that we accept the "Alternate Proposed Resolution" from 2775(i).
[ Original rationale: ]
The LWG did not reach a consensus for a change to the WP.
Previous resolution [SUPERSEDED]:
In the class template
reverse_iterator
synopsis of 24.5.1.2 [reverse.iterator] change as indicated:namespace std { template <class Iterator> class reverse_iterator : public iterator<typename iterator_traits<Iterator>::iterator_category, typename iterator_traits<Iterator>::value_type, typename iterator_traits<Iterator>::difference_type,typename iterator_traits<Iterator&>::pointer, typename iterator_traits<Iterator>::reference> { public: [..] typedeftypename iterator_traits<Iterator&>::pointerpointer; [..] protected: Iterator current; private: mutable Iterator deref_tmp; // exposition only };- Change [reverse.iter.opref]/1 as indicated:
pointer operator->() const;1
ReturnsEffects:&(operator*())
.deref_tmp = current; --deref_tmp; return deref_tmp;[Alternate Proposed Resolution from 2775(i), which was closed as a dup of this issue]
This wording is relative to N4606.
Modify [reverse.iter.opref] as indicated:
constexpr pointer operator->() const;-1-
Returns:Effects: Ifaddressof(operator*())
.Iterator
is a pointer type, as if by:Iterator tmp = current; return --tmp;Otherwise, as if by:
Iterator tmp = current; --tmp; return tmp.operator->();
[2018-08-06; Daniel rebases to current working draft and reduces the proposed wording to that preferred by LEWG]
[2018-11-13; Casey Carter comments]
The acceptance of P0896R4 during the San Diego meeting resolves this
issue: The wording in [reverse.iter.elem] for operator->
is equivalent to the PR for LWG 1052.
Proposed resolution:
This wording is relative to N4762.
Modify 24.5.1.6 [reverse.iter.elem] as indicated:
constexpr pointer operator->() const;-2-
Returns:Effects: Ifaddressof(operator*())
.Iterator
is a pointer type, as if by:Iterator tmp = current; return --tmp;Otherwise, as if by:
Iterator tmp = current; --tmp; return tmp.operator->();