Re: [Boost-users] [mpl|fusion|tr1]mpl::at_c<std::tr1::tuple<...>, I>::type fails

From: John C. Femiani (john.femiani_at_[hidden])
Date: 2008-08-25 10:02:35

Markus Werle wrote:
> Markus Werle <numerical.simulation <at> web.de> writes:
>
>   
>> Hi!
>>
>> I am using boost_1_36_0 manually patched with the files mentioned in
>> http://thread.gmane.org/gmane.comp.lib.boost.user/39093/focus=39106
>>
>> I thought that std::tr1::tuple was a valid mpl sequence, but this 
>> code here fails. Is this by design?
>>
>> ---snip---
>> #include <boost/tr1/tuple.hpp>
>> #include <boost/mpl/assert.hpp>
>> #include <boost/mpl/at.hpp>
>>
>> template <typename Tuple, long I>
>> struct
>> show_problem
>> {
>> 	typedef typename boost::mpl::at_c<Tuple, I>::type type;
>> };
>>
>> int main()
>> {
>>  	typedef std::tr1::tuple<int, int> tuple_t;
>>
>>  	typedef boost::mpl::at_c<tuple_t, 1L>::type Ouch;
>> }
>>     
>
> It's std. So it has to make a difference:
>
> typedef std::tr1::tuple_element< 1L, tuple_t>::type OK;
>
> Looks like we end with a plethora of different compile-time sequences
> all using different element access semantics, leaving us with an uncomfortable 
> feeling about the TR1 ... where will this end?
>
>
> Markus
>   
Did you #include <boost/fusion/tuple.hpp>?  That one got me a while ago 
with Boost.Tuple -- apparently tuples are Fusion sequences *after* you 
include the header that adapts them...

--John