Re: input iterators and post increment
On 2013-07-25 15:53, fmatthew5876 wrote:
I don't understand what you mean. If your input iterator returns a
proxy result, there is no reason why this could cause the code to be
dangerous that could lead to random crashes. Would you please
elaborate?
But what value would the proxy object have? Set it to the value of
the previous iterator?
As I explained in my first (corrected) response to you:
"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."
There is no need for the proxy to store the iterator (in fact, it really
should not store such a copy!), it suffices that it contains a copy of
the *value type* of the value *before* the incrementation happened. In
other words: For pure input iterators, the post-increment operator does
also dereference the current iterator to obtain its current value!
Most importantly, where is it stored? In the
iterator itself? Great, every iterator now grows by sizeof(T) just
for this one case. As a static object? That wouldn't work for thread
safety. On the heap? Now we're hitting the memory allocator. This
is very slow, imagine if someone writes a post increment loop,
correctly throwing away the result. Every increment now does a
useless new and delete and nobody can even tell this is happening by
just looking at the code. Also now you have to track ownership,
handle moves/copies etc..
These arguments are all mood, given above explanation. There is no need
that input iterators have to reserve additional memory just to implement
a rarely used function.
What happens if you increment the iterator holding
a proxy? The madness goes on and on. Better to just crash and
tell the programmer don't do that!
No need for that, really.
Basically my iterator class looks like this.
class Container::iterator {
I'm just realizing that you seem to have a container here. I'm not sure
whether it is one that corresponds to the requirements of a Standard
Library Container, but if so, they are required to return forward
iterators. But this is just a side commented not really related to your
actual problem at hand.
public:
iterator()
: _first(nullptr), _last(nullptr), _parent(nullptr)
T& operator*() { assert(_first != nullptr); return *_first; }
T* operator->() { assert(_first != nullptr); return _first; }
iterator& operator++() {
assert(_first != nullptr);
if(_first != _last) {
++_first;
} else {
_parent->giveMeMore(&_first, &_last);
}
return *this;
}
iterator operator++(int) {
++(*this);
return iterator(); //<-asserts on dereference
}
This is incorrectly implemented, because a user is allowed to
dereference the result of the postfix increment operation:
*iter++
is a supported operation. Instead return something like this:
struct proxy {
value_type& operator*() const {
return value;
}
private:
friend class Container::iterator;
explicit input_iterator_postfix_increment_result(
const Container::iterator& iter)
: value(*iter) { }
mutable value_type value;
};
and implement post-increment like this:
proxy operator++(int) {
proxy result(*this);
++(*this);
return result;
}
private:
T* _first;
T* _last;
Container* _parent;
friend class Container;
iterator(T* f, T* l, Container *p)
: _first(f), _last(l), _parent(p) {}
};
The standard allows for past iterators to become invalidated. Instead
of waiting for this to happen by chance, I do it every time.
Dereferencing a past input iterator in this case is a programmer
error and thus should be caught and fixed as early as possible.
There is no need for such rigorous behaviour, because post-increment can
be implemented without such harmful effects.
It's inefficient for many non-pointer iterators, but it is not
dangerous. I don't think that an efficiency argument alone could
convince the committee to break code that exists since decades.
It is dangerous for input/ouput iterators.
No, it isn't, if correctly implemented.
It wouldn't break any code. The STL would simply stop calling
post-increment if it ever does and always use pre-increment. Anyone
who has correctly implemented an iterator has always implemented
pre-increment and copy construction.
The "STL" is not the only user of the iterator requirements contract,
this contract is used in many third party libraries which rely on that
specification. Again, I think this should better be solved by a revised
set of iterator requirements instead of breaking the existing ones.
HTH & 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! ]