[mpl|fusion|tr1]mpl::at_c<std::tr1::tuple<...>, I>::type fails
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; }
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
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
participants (2)
-
John C. Femiani -
Markus Werle