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

Subject: Re: [boost] [fusion] pop_back doesn't work on fwd sequences
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-08-12 02:33:02

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_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.

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