Re: [Boost-users] Boost range changes [1.37.0]

Subject: Re: [Boost-users] Boost range changes [1.37.0]
From: Robert Jones (robertgbjones_at_[hidden])
Date: 2008-11-20 17:32:47

On Wed, Nov 19, 2008 at 10:15 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Tomas Puverle skrev:
>
>> I just upgraded from Boost 1.33.1 to 1.37.0 and have found a breaking
>> change in
>> Boost.Range.
>>
>> Previously, iterator_range::empty() would do the following:
>>
>>            bool empty() const
>>            {
>>                if( singular )
>>                    return true;
>>                                return m_Begin == m_End;
>>            }
>>
>> and similarly for size().  In the new release, instead of the test, there
>> is an
>> assertion, which is now breaking my code.
>>
>> Why (and when?) was this change introduced?  This make Boost Range much in
>> generic code, such as
>>
>> template<class Range>
>> void foo(const Range & r_)
>> {
>>  if (r_.empty()) {...}
>> }
>>
>> The code is frequently called with containers and ranges and works
>> beautifully.  However, a common pattern is to call the function with a
>> default constructed
>> (empty range).  This now crashes.  The only way to test for validity
>> AFAICS is
>> to call is_singular(), unfortunately, this breaks when the function is
>> called
>> with containers.
>> This, IMHO, was an unfortunate decision.  Any suggestions anyone?
>>
>
> The change has happened long ago. It was a design mistake to try to make a
> range of singular iterators valid since it adds overhead also for those that
> don't need it.
>
> Your use-case is new to me, but seems quite ok. But making
> boost::iterator_range as a mixture of a range and boost.optional seems like
> a bad idea.
>
> template<class Range>
> void foo(boost::optional<const Range &> r_)
> {
>  if (r && !r_->empty()) {...}
> }
>
> might be an idea?
>
>
I too feel this change is a retrograde step. While I can see that there is
some merit in
not making a singular range valid if we are starting from square-one, as a
change to an
existing library I think this unacceptable.

Having a default constructed iterator range exhibit different behaviour
from, say, a vector,
which is also a range seems wrong.

- Rob.