Re: [Boost-users] A forward iterator need not be default-constructible

Subject: Re: [Boost-users] A forward iterator need not be default-constructible
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-09-29 16:37:17

> Yes; this is a problem with negative requirements statements.  Just like
> you can't decrement a forward iterator, you can't dereference a singular
> iterator.

The characterization "just like" is a little off. Trying to decrement
a forward iterator is a conceptual error. Trying to dereference an
iterator with a singular value is a logic error.

I think we get into trouble when we talk about "valid iterators". I
don't think there's such really such a thing at all. There may be
cases where it's valid to decrement an iterator, but not dereference
it. There may be cases where it's valid to dereference an iterator but
not decrement. A PTE iterator is well-formed, but both incrementing
and dereferencing is invalid.

> The point is that the OP claimed every default-constructed iterator is
> singular.  The only way that could be true is if you take the term
> "is-a" in the sense I'm using it here.  That is, I can easily create an
> iterator that, when default-constructed, supports a strict superset of
> the required operations for singular iterators.

Without any strong guarantees about the state of default constructed
iterators in general, I don't think I'd try to use them in a generic
algorithm. This is just begging for trouble:

template<typename I>
  auto f() { I i; assert(*i); } // worst algorithm ever

If I know that the iterator has valid operations after being default
constructed, then I'll do as I like -- whatever the concept does or
does not say.

counting_iterator<int> i(0);
cout << *i <<; // should work just fine