Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Dave Handley (dave_at_[hidden])
Date: 2008-11-22 11:13:50

<snip>
>
> With such a notion this, indeed, is a rather useless component. I have to
> agree with Tomas and others in one of their points: one of the major
> advantages or ranges before pairs of iterators is that they attempt to
> reproduce containers as far as possible. Yes, in general 
> default-constructed
> iterators are singular and they cannot be used reliably. However, not all
> iterators behave that way. Pointers, for example, are NULL on
> default-initialization (which is used in the default constructor of the
> iterator_range class). I can well have my own iterators that are
> default-constructible and allow comparison in this state. And I don't
> understand why an iterator range of these iterators suddenly restricts me
> from being able to compare these iterators in empty(), for example.
>
> The documentation of the iterator_range states for several functions, such
> as size() and operator[], that these functions depend on the iterator
> nature. I believe, empty() could just do the same - rely on the ability to
> compare iterators, even default-initialized ones. Of course, this should 
> be
> clearly stated in the docs.

Whilst the documentation might say that, the implementation of size() and 
operator[] depends on underlying iterator nature, the reality is that both 
these functions will assert on a singular range.

>
> If it was just me, default-constructing iterators and ranges shouldn't 
> even
>> be allowed (unless that is sufficient that initialize it).
>> A range that is not properly initialized is not in any usable state. It's
>> not an empty range, it's more like a pointer to somewhere random. Just 
>> don't
>> try to use it. If Boost.Range used to allow it, that was a bug; good 
>> thing
>> it is now fixed.
>>
>
>> As for is_singular, that function shouldn't be exposed to the public.
>
>
> I agree that is_singular is evil. More over, I am sure that asserts based 
> on
> it are also evil. My point is: don't try to make iterator_range more 
> clever
> than it is stated in the docs (that is, a pair of iterators with a
> forwarding interface of a container).

This is the crux of the issue.  What is an iterator_range trying to be.  If 
it is supposed to be nothing more than a glorified pair of iterators, then 
so be it.  Allow singular ranges, but don't assert on them.  If on the other 
hand it wants to make a pair of iterators look like a container, then there 
pretty much has to be a way to create an empty range without having to tie 
that empty range to a specific container.  The glorified pair will only ever 
get used as a glorified pair.  A pair of iterators looking like a container 
though is far more useful in generic programming - so that would be my 
personal proposal.  At the moment, iterator_range is trying to be both 
things, and failing at both as well.

Dave