Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-11-23 07:56:47

Andrey Semashev skrev:
> On Sat, Nov 22, 2008 at 8:13 PM, Mathias Gaunard <
> mathias.gaunard_at_[hidden]> wrote:
> 
>> Andrey Semashev wrote:
>>
>>  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.
>>>
>>
>> Iterators where default-construction leads to a valid past-the-end iterator
>> for all sequences are a fairly special case of iterators, even if they
>> happen to be quite common.
>> However, that is certainly not guaranteed by the iterator concepts.
>> Therefore, when you deal with iterators in a generic way, you should not
>> assume such a thing.
>>
>> iterator_range being a generic tool, it wants to maintain the invariants
>> which are necessary to make it work whatever its parameters are, even if
>> those invariants happen not to be necessary for some parameters.
>>
> 
> I think this is the case when excessive invariant checking does more harm
> than good. I hate to reiterate, but I think it should be up to user whether
> to rely on the ability to compare default-constructed iterators or not. The
> library, being as you rightfully say, a generic tool, must not impose
> excessive restrictions on the use model of the underlying iterators. Right
> now the library does so, which basically cancels a considerable set of valid
> use cases. I would say, it contradicts the term "a generic tool".
> 

Your views have some merits, and I think we should have a more 
conservative debugging policy in iterator_range.

-Thorsten