Boost logo

Boost :

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
to provide.

Eric Niebler
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at