Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-11-23 16:18:57

On 2008-11-22, Tomas Puverle <Tomas.Puverle_at_[hidden]> wrote:
>
> Why would you ever want to create an empty container?

To add stuff to it, but you can't do that with a range.

> 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.
>

What sequence do those iterators iterate?  I don't see what it could
be that wouldn't let you get at least the PTE iterator even if the
representation doesn't "point to a valid entry", so you ought to be
able to just

     return MyRange(end, end);

And the iterator range constructor is a perfectly legal container
construct too, so it doesn't break your desire to use containers in
the same code path.

So I don't see how there "no way to reproduce" the behaviour, at least
in the outline of code you provided.