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

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 <brian.w.allison-AT-gmail.com> 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
http://www.boostpro.com