Re: input iterators and post increment
On 2013-07-24 10:01, fmatthew5876 wrote:
I'm using input iterators to implement an asynchronous IO system.
Whenever you increment an input iterator, all copies of the previous
value can become invalidated. Indeed, this is the case in my example as
blocks of data come in and are released back to the system as the
iterator marches forward.
So my question in all this is why does the input iterator require post
increment?
It seems like an inherently broken and unsafe operation to support,
given that the only feature proffered by the useless return value is
the opportunity to write bugs by accidentally dereferencing it.
Would it break STL algorithms or in some other way be incorrect to only
implement pre-increment?
What about this variant?
void operator++(int);
Or just do the same as pre-increment?
iterator& operator++(int) { return ++(*this); }
If it must be implemented, perhaps the best practice is instead of returning
a copy of the previous iterator, return an iterator with some sentinel
values like setting all of its internal pointer data members to nullptr and
then asserting on that in the dereference.
I need to extend my first response to your question, because it was
incomplete and due to that contained a false conclusion. As of writing
this, it has not appeared yet. Even though the direct requirements for
input iterators on post-increment would allow for a function that
returns simply void, we also need to satisfy the additional constraint
that the expression
*r++
is valid and returns a type that is convertible to the value type of the
iterator. A typical solution is to return a proxy class that provides
operator* and that returns a copy of the referenced value before the
incrementation happened.
My apologies for the hast of my first reply && Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]