|
Boost : |
Subject: Re: [boost] [fusion] pop_back doesn't work on fwd sequences
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-08-10 14:18:36
On 8/10/2011 2:51 PM, Eric Niebler wrote:
> On 8/9/2011 11:17 PM, Joel de Guzman wrote:
>> On 8/10/2011 12:56 PM, Eric Niebler wrote:
>>> A sequence created by push_back is a Forward Sequence, which means you
>>> can't call pop_back on it. I think that's a serious shortcoming. Fusion
>>> needs something like MPL's Back Extensible and Front Extensible concepts.
>>>
>>> http://www.boost.org/doc/libs/1_47_0/libs/mpl/doc/refmanual/back-extensible-sequence.html
>>>
>>> Unfortunately, this would likely require a redesign of the whole
>>> (push|pop)_(front|back) mechanism.
>>
>> Man, this is a major bummer, alright. One plausible clean way I can think of is:
>>
>> 1) Make single_view random_access (if it's not already; IIRC No).
>
> I implemented this not too long ago.
>
>> 2) Make joint_view assume the least sequence category of its subsumed sequences.
>> There's already some work done related to this where joint_view inherits
>> the 'associative'-ness of its held sequences.
>
> I don't think that's good enough. Take my example above. In,
> push_back(nil(), 1), the traversal type of nil is Forward, and so too
> would be the resulting view. It probably makes sense to see how MPL
> manages it.
Fusion diverges from MPL in its design in that sequence extension in
Fusion always results to an 'extended' view (e.g. joint_view), instead
of MPL's sequence-type-preserving operations. That is primarily for
the sake of runtime efficiency (e.g. you do not want to have to
build a new vector when you push_back an element). For that reason,
I do not think it is a good idea to manage it like MPL.
That example of yours [ push_back(nil(), 1) ] can also be made to
work by making 'nil' random-access. In essence, we should give all
sequences the highest potential traversal category that we can.
Regards,
-- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk