Proposal for New Iterator Adaptor
I realize that this isn't the best time for proposals, what with everyone trying to get the next release of boost out, but I have an idea for a new iterator adaptor which I'd like to propose. Consider an adapted iterator type Iter with base iterator type Base that has the following traits: typedef Base value_type; typedef const Base & reference; When you dereference an instance of the adapted iterator type Iter, you get a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like that. There are some interesting things that you can do with this. For example: typedef std::vector< CString > vector; typedef std::vector< vector::iterator > iter_vector; typedef lazy_iterator< vector::iterator > lazy_iter; vector my_vector; iter_vector my_iter_vector; ... std::unique_copy( lazy_iter( my_vector.begin() ), lazy_iter( my_vector.end() ), std::back_inserter( my_iter_vector ), indirect_equal_to()); where indirect_equal_to is a special binary predicate which is defined like this: struct indirect_equal_to { template <typename Iter> bool operator==(Iter a, Iter b) { return *a == *b; } }; After this call to std::unique_copy(), my_iter_vector is a sequence of iterators that point to the unique elements in my_vector. Typically, you would just copy the unique elements into another vector of strings, but the approach described here is advantageous if you need to access the original unique elements in my_vector (for instance, if you need to change them), or if you want to avoid the overhead of copying strings. You could also have an iterator adaptor type Iter whose dereferencing operator returns &(*b), where b is its base iterator of type Base. This could be useful for generating ranges of pointers from ranges of objects. I think that this would be a useful iterator adaptor that would complement indirect_iterator very nicely. Whereas indirect iterator is useful for performing operations on ranges of iterators, this adaptor is ideal for generating ranges of iterators. Is anyone else interested in this? Thanks, Alex Chovanec
Alex, Alex Chovanec wrote:
I realize that this isn't the best time for proposals, what with everyone trying to get the next release of boost out, but I have an idea for a new iterator adaptor which I'd like to propose.
Consider an adapted iterator type Iter with base iterator type Base that has the following traits:
typedef Base value_type; typedef const Base & reference;
When you dereference an instance of the adapted iterator type Iter, you get a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like that.
IIUC it's currently named counting_iterator. I.e. the main point of counting_iterator isn't the counting but the non-dereferencing. Where does your idea differ from counting_iterator? Thomas -- Thomas Witt witt@acm.org
You're right. It's the same idea. I looked at counting_iterator once before, but I somehow developed the impression that it was something more specialized. As you suggest, I think I was a bit thrown off by the name. This was actually a necessary prerequisite for another library that I was going to propose, so I'm glad to see that it's already in there. : ) Sorry for the redundant post. Alex "Thomas Witt" <witt@acm.org> wrote in message news:cf053d$rk3$1@sea.gmane.org...
Alex,
Alex Chovanec wrote:
I realize that this isn't the best time for proposals, what with
trying to get the next release of boost out, but I have an idea for a new iterator adaptor which I'd like to propose.
Consider an adapted iterator type Iter with base iterator type Base that has the following traits:
typedef Base value_type; typedef const Base & reference;
When you dereference an instance of the adapted iterator type Iter, you get a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like
everyone that.
IIUC it's currently named counting_iterator. I.e. the main point of counting_iterator isn't the counting but the non-dereferencing. Where does your idea differ from counting_iterator?
Thomas
-- Thomas Witt witt@acm.org
_______________________________________________ Unsubscribe & other changes:
From: "Alex Chovanec" <achovane@engin.umich.edu>
When you dereference an instance of the adapted iterator type Iter, you get a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like that.
The idea is intriguing, but the iterator isn't lazy, it just doesn't dereference ("lazy" suggests that it will do the work on demand, not immediately). A better name would be "deferred_iterator" or "iterator_iterator." -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
From: "Alex Chovanec" <achovane@engin.umich.edu>
When you dereference an instance of the adapted iterator type Iter, you
get
a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like
Believe it or not, deferred_iterator was the other name that I was considering, but now I see that it's already in the library as counting_iterator. Alex "Rob Stewart" <stewart@sig.com> wrote in message news:200408061508.i76F8g120778@entwistle.systems.susq.com... that.
The idea is intriguing, but the iterator isn't lazy, it just doesn't dereference ("lazy" suggests that it will do the work on demand, not immediately). A better name would be "deferred_iterator" or "iterator_iterator."
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes:
participants (3)
-
Alex Chovanec -
Rob Stewart -
Thomas Witt