[Boost-users] [fusion] is there anything resembling a joint_view of 2 maps?

3 views
Skip to first unread message

er

unread,
Sep 19, 2009, 11:07:29 PM9/19/09
to boost...@lists.boost.org
Hi All,

I am wondering if anyone knows of anything that resembles a joint_view
of a pair of maps.


typedef mpl::int_<1> key1_;
typedef mpl::int_<2> key2_;

typedef pair<key1_,int> pair1_;
typedef pair<key2_,int> pair2_;

typedef map<pair1_> map1_;
typedef map<pair2_> map2_;

map1_ m1( make_pair<key1_>(1) );
map2_ m2( make_pair<key2_>(2) );
typedef joint_view<
map1_,
map2_
> jv_;

// not supposed to compile (?), yet it does:
jv_ view(m1,m2);
// but not this:
// at_key<key1_>(view)

// I have no choice (?) but create a new map,
// although view helps a bit for initializing it:
typedef map<
pair1_,
pair2_
> map3_;

map3_ m3 = fusion::as_map(view);

int n1 = fusion::at_key<key1_>(m3);
BOOST_ASSERT(n1 == 1);
int n2 = fusion::at_key<key2_>(m3);
BOOST_ASSERT(n2 == 2);


_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Christopher Schmidt

unread,
Sep 20, 2009, 5:55:41 AM9/20/09
to boost...@lists.boost.org
The current implementation of views do not preserve the associative-ness
of the underlying sequence(s). In your specific example, the joint_view
is a plain forward sequence.

You could try my c++0x-port of Boost.Fusion. My implementation correctly
preserves the category. You can find the code in the sandbox
(https://svn.boost.org/trac/boost/browser/sandbox/SOC/2009/fusion).

-Christopher

er schrieb:

er

unread,
Sep 20, 2009, 11:50:36 AM9/20/09
to boost...@lists.boost.org

> You could try my c++0x-port of Boost.Fusion. My implementation correctly
> preserves the category. You can find the code in the sandbox
> (https://svn.boost.org/trac/boost/browser/sandbox/SOC/2009/fusion).
>
> -Christopher
>

Thank you.

I guess it wouldn't be a good idea for me to mix files from
c++0x-port and boost.

To those who support fusion: would it be wise to place a feature request
for this, then?

Christopher Schmidt

unread,
Sep 20, 2009, 12:23:39 PM9/20/09
to boost...@lists.boost.org
My code is pretty much backwards compatible - there have not been any
striking semantic changes and all testcases pass on gcc 3.4/4.4 and vc 9.
Unfortunately I have not had the time to put the code up for review yet.
I am pretty positive that the code is trunk-ready though, and I will try
to post a report on my work within the next days.

Either way, for now you can workaround your issue by providing your own
extension implementations for
fusion::extension::category_of_impl<fusion::joint_view_tag>,
fusion::extension::has_key_impl<fusion::joint_view_tag> and
fusion::extension::at_key_impl<fusion::joint_view_tag>, or, even better,
wrap the joint_view up in another view which implements both (forward
and associative) extension backends.

-Christopher

er schrieb:


> I guess it wouldn't be a good idea for me to mix files from
> c++0x-port and boost.

_______________________________________________

Joel de Guzman

unread,
Sep 20, 2009, 8:42:15 PM9/20/09
to boost...@lists.boost.org
er wrote:
>
>> You could try my c++0x-port of Boost.Fusion. My implementation
>> correctly preserves the category. You can find the code in the sandbox
>> (https://svn.boost.org/trac/boost/browser/sandbox/SOC/2009/fusion).
>>
>> -Christopher
>>
>
> Thank you.
>
> I guess it wouldn't be a good idea for me to mix files from
> c++0x-port and boost.
>
> To those who support fusion: would it be wise to place a feature request
> for this, then?

Yes, please. Christopher, would you be interested to port to
current fusion? That would provide a seamless integration from
the current code to the future 0x code.

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net
http://tinyurl.com/facebook-jdg

Christopher Schmidt

unread,
Sep 21, 2009, 1:20:01 PM9/21/09
to boost...@lists.boost.org
I certainly am. Once the review of my port is done, I will start working
on it.

-Christopher

Joel de Guzman schrieb:


> Yes, please. Christopher, would you be interested to port to
> current fusion? That would provide a seamless integration from
> the current code to the future 0x code.
>
> Regards,

_______________________________________________

er

unread,
Oct 22, 2009, 5:34:37 PM10/22/09
to boost...@lists.boost.org

> Either way, for now you can workaround your issue by providing your own
> extension implementations for
> fusion::extension::category_of_impl<fusion::joint_view_tag>,
> fusion::extension::has_key_impl<fusion::joint_view_tag> and
> fusion::extension::at_key_impl<fusion::joint_view_tag>, or, even better,
> wrap the joint_view up in another view which implements both (forward
> and associative) extension backends.
>


Thanks, but the workaround you are suggesting is not obvious to me.
Maybe you can help? I have started here :

template <>
template<typename Seq1,typename Seq2,typename Key>
struct at_key_impl<joint_view_tag>::apply<
joint_view<Seq1,Seq2>,Key
>
{
typedef joint_view<Seq1,Seq2> jv_;

typedef fusion::result_of::has_key<Seq1,Key> has_key1_;
typedef typename mpl::if_<
has_key1_,
Seq1,
Seq2
>::type seq_;


typedef typename result_of::at_key<seq_,Key>::type type;


static type
call(jv_& m)
{
// return m.at_impl(mpl::identity<Key>());
????

}
};

Reply all
Reply to author
Forward
0 new messages