On 2008-11-22, Tomas Puverle <Tomas.Puverle@morganstanley.com> 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.