Subject: Re: [boost] [fusion] mpl::clear doesn't work on fusion views
From: Eric Niebler (eric_at_[hidden])
Date: 2011-07-29 17:45:45
On 7/29/2011 1:36 PM, Jeffrey Lee Hellrung, Jr. wrote:
> On Fri, Jul 29, 2011 at 12:52 PM, Eric Niebler <eric_at_[hidden]> wrote:
>> Today I ran into a limitation in Fusion/MPL interoperability. I couldn't
>> use an mpl algorithm on a Fusion sequence because mpl::clear wasn't
>> defined on it. The sequence was a joint_view. I see that
>> fusion::detail::clear is only defined for Fusion cons, map, set, vector
>> and deque. Can we get it defined for all Fusion sequences? I think for
>> everything else, an empty Fusion vector would do. That is all
>> fusion::clear does, btw.
>> (Aside: it seems strange to me that mpl::clear of a fusion::set gives an
>> empty set, but that fusion::clear of an empty set gives an empty vector.
>> This should probably be made consistent.)
> I'm confused. Why would fusion::detail::clear (which I presume is
> associated with fusion::clear) have anything to do with mpl::clear?
Because all Fusion sequences are also MPL sequences.
> Also, mpl::clear requires an MPL Extensible Sequence, which...I'm guessing
> fusion::joint_view doesn't satisfy...? So either make fusion::joint_view an
> MPL Extensible Sequence, or relax the requirements on mpl::clear...? I'm
> not sure either make sense, really.
Ah. Certainly a fusion::joint_view is not extensible. But that's a weak
rationale because it's not how Fusion operates. A push_back on a Fusion
vector yields a joint_view, not a Fusion vector. Clearing any Fusion
sequence could just yield an empty vector, like fusion::clear does (with
the caveat stated above).
> I guess there's some reason you don't want to or can't copy the types in the
> joint_view into an mpl::vector and operate on that instead?
Because I'm lazy. And because Fusion can do this. And it's a reasonable
thing to expect. And the patch would be about 3 lines, which I'm happy
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk