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-10-01 14:07:25

on Sat Oct 01 2011, Krzysztof Żelechowski <giecrilj-AT-stegny.2a.pl> wrote:

> Andrew Sutton wrote:
>
>>>> template<typename I>
>>>> auto f() { I i; assert(*i); } // worst algorithm ever
>> 
>>> OTOH, if I know that a singular iterator of some type would have no valid
>>> operations, and the iterator is only meant to be used by algorithms, the
>>> benefit of being unable to create a singular iterator (like when the
>>> iterator in question holds a reference to supporting data used in its
>>> operation) outweighs the benefit of being able to do so.
>> 
>> I think I've lost the thread of the argument. Are you saying that you
>> should *not* be able to default construct iterators?
>
> What I am saying is that iterators that are not default-constructible are 
> sometimes more robust because an attempt to create them out of thin air 
> results in a compile-time error.  

Yes... except that they are not iterators.

> I am not saying that all iterators are like that (I agree with Dave
> regarding his the interpretation of NULL).  Moreover, such iterators
> sometimes come up naturally from standard components (and not some
> shady third-party ones, as has been suggested), as evidenced in my
> code that fails to compile with Boost concepts.

Sorry, which code was that?

> Being a singular iterator is not a concept, it is a run-time property.
> The compiler cannot check whether an operator is singular, 
> it is equivalent to the halting problem.

It can't check whether an iterator is random-access either.  All (good)
concepts have semantic constraints that can't be checked by the
compiler.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com