Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-22 13:12:08

Scott, 

> But what semantics for empty *are* documented?
> 
> http://www.boost.org/doc/libs/1_37_0/libs/range/doc/boost_range.html
> #Semantics
> empty(x) returns boost::begin(x) == boost::end(x)

Prior to 1.35, the iterator_range<> documentation read the following:

"Recall that many default constructed iterators are singular and hence can only
be assigned, but not compared or incremented or anything. However, if one
creates a default constructed iterator_range, then one can still call all its
member functions. This means that the iterator_range will still be usable in
many contexts even though the iterators underneath are not. "

Does this answer your question?

> Why would you ever want to pass a default-constructed range to anything?

Why would you ever want to create an empty container?  Let me give you an
example of one of the ways I use empty ranges, which I've found extremely 
useful:

typedef iterator_range<SomeIterator> MyRange;

class MyIterator: public boost::iterator_facade<... MyRange >
{
  private:
    MyRange dereference() const
   {
        //if the internal representation is point to a valid entry (say 
        //in a file) return a set of valid iterators, otherwise return 
        //an empty range
        if (...)
        {
            return MyRange(....);
        }   
        else
        {
            return MyRange();
        }     
   }    
};

typedef iterator_range<MyIterator> Range2;

Range2 r1(...);
Range2 r2(...);

Now one can work with these ranges recursively, because of the overloaded
operators of boost::iterator_range, e.g.

r1 == r2;
or 
r1 != r2;

I can also write generic code which can take list of vectors of iterators or
perhaps can just read the data directly from the file representation or what 
not.  

Now, there is no way to reproduce this behaviour with the new implementation.

Best wishes,

Tom