Re: [boost] [fusion] pop_back doesn't work on fwd sequences

Subject: Re: [boost] [fusion] pop_back doesn't work on fwd sequences
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-08-12 02:12:28

On Thu, Aug 11, 2011 at 10:32 PM, Joel de Guzman
<joel_at_[hidden]>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.

> 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...).
- I include a 3rd template parameter, Traversal, which defaults to the
Iterator_'s category_of, and allows one to override the traversal category.
- 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
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...
- I also include default implementations of key_of, value_of_data, and
deref_data.

- Jeff