
on Sat Oct 01 2011, Krzysztof Żelechowski
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