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.