On 8/12/2011 2:12 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Aug 11, 2011 at 10:32 PM, Joel de Guzman <joel@boost-consulting.com>wrote:
On 8/12/2011 4:04 AM, Jeffrey Lee Hellrung, Jr. wrote:
Regarding fusion::iterator_adaptor, great! I had rolled my own junk implementation (and used it to implement some move_iterator-like iterators) so it would be good to just pull something from Boost.Fusion.
If you want me to share what I had written (mine's relatively simple), let me know.
Sure. I'd love to see your move_iterator-like iterators (if that's what you mean) if you can port it to the new iterator_adaptor thingy.
Well, it's not what I meant, but I can share those, too. Perhaps better to wait until iterator_adaptor is settled and Ion's Boost.Move is in a release. I have a move_iterator and move_owned_iterator, both using Ion's Move; the latter only moves elements of a sequence whose value_of is a non-reference type.
Ok.
If you mean your own 'iterator_adaptor' implementation, It would be better if you can peruse and review the one in the trunk and tell me if you can suggest improvements (so far, it has not been tested yet).
Okay, here are the functional differences between our implementations:
- I use the category_of metafunction rather than Iterator_::category (I don't recall offhand if a nested ::category is required for Fusion iterators, so these could very well be interchangeable...).
It is, in the implementation POV. category_of is better though for the sake of struct concept conformance.
- I include a 3rd template parameter, Traversal, which defaults to the Iterator_'s category_of, and allows one to override the traversal category.
Nice idea.
- I do *not* have default implementations of next, prior, and advance, instead forcing the derived class to implement these, if desired; I notice you require the derived class to implement a make metafunction, which I guess is fine, but then shouldn't iterator_adaptor::advance::call use something like Derived_::make::call, so ultimately put the iterator
You are looking at a slightly older version. It's been fixed.
construction responsibility on the derived class? If so, I'm not sure if providing default implementations of next, prior, and advance is really all that convenient...
Consider a transform iterator where you want a next, prior, advance to do as usual, but 'override' the behavior of value_of and deref to do your bidding. In that common case, you do not want to bother with the reimplementations.
- I also include default implementations of key_of, value_of_data, and deref_data.
Good! I'd welcome a merge. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com