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

on Thu Sep 29 2011, Brian Allison wrote:

On Thu, Sep 29, 2011 at 3:59 PM, Dave Abrahams wrote:

Your ontology seems to have no basis in the ontology of the standard. The last sentence I quoted:

Dereferenceable values are always nonsingular.

This sentence doesn't leave room for a statement like "every valid iterator is-a singular iterator in some sense", given that dereferenceable iterators are valid, and the standard explicitly states that they are non-singular. Your definition of "in a sense" and "in teh same way" are then in contradiction to the standard.

Not if a nonsingular iterator is-a singular iterator. That way of using is-a is the only sense that makes the OP's claim true. Either you have to accept that way of using is-a or you have to reject the OP's claim. I'm able to use and think about "is-a" that way, and if you chafe at the idea that a nonsingular iterator is-a singular iterator, that's fine with me. I think that means you have to reject the claim that all default-constructed iterators are singular, which is also fine with me.

When the standard says "that's a singular iterator" it's saying you can only assume it supports two operations.  That doesn't mean it can't support more operations.  It's a constraint on the user, not on the iterator.

But when it says "Dereferenceable values are always nonsingular.", that seems to be a constraint on the iterator. Being X or Non-X are mutually exclusive.

That's the crux of the issue. If you believe that, there's no way the OP's claim can be true.

In the sense of concept requirements, you can.  Any valid iterator supports a superset of the requirements on singular iterators

If you're only concerned with the positive requirements of a concept, then yes. But we must be concerned with both positive and negative requirements - since the standard explicitly excludes dereferenceable values from being singular, then being "singular" doesnt' really map well to concept requirements [if I understand your contextual use of the term].

OK, that's another way to say it.

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.

But I could make an iterator type whose constructor would throw() if it were not to a valid member.

Sure. That's actually a valid (if perverse) iterator. But then, you could make an iterator where every operation throws unconditionally.

A contrived example, but then there would be a type which would refute OP's claim while adhering to the standard.

Refuting the OP's claim while adhering to the standard doesn't require such contortions: // untested struct charp : boost::iterator_adaptor { charp() : charp::super_t(0) {} // <== voilà charp(charp const& rhs) : charp::super_t(rhs) {} }; charp() == charp(); // defined behavior charp() != charp(); // defined behavior charp() < charp(); // defined behavior charp() > charp(); // defined behavior charp() > charp(); // defined behavior charp x, y = x; // defined behavior

Curiosity: why are you trying to form an algebra in which the OP's claim is correct?

My point is that even if such an algebra exists, it doesn't mean what the OP thinks it means. -- Dave Abrahams BoostPro Computing http://www.boostpro.com