Boost logo

Boost Users :

Subject: Re: [Boost-users] A forward iterator need not be default-constructible
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-09-30 11:22:29

on Thu Sep 29 2011, Brian Allison <> wrote:

> On Thu, Sep 29, 2011 at 3:59 PM, Dave Abrahams <dave_at_[hidden]>
> 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<char*>
         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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at