[iterators] zip_iterator doesn't work with GCC's TR1 tuple?
Has anybody successfully used Boost.Iterator's zip_iterator with TR1 tuples from GCC's libstdc++? I keep getting errors like "error: no type named 'head_type' in 'class std::tr1::tuple<..." when using TR1 tuples with the zip_iterator implementation in Boost 1.35.0 -- am I missing something? I have code like this: using namespace std::tr1; vector<tuple<string, int, tuple<string, string, string> > > result; copy( make_zip_iterator( make_tuple( string_vector.begin(), int_vector.begin(), make_zip_iterator( make_tuple( string_vector1.begin(), string_vector2.begin(), string_vector3.begin() ) ) ) ), make_zip_iterator( make_tuple( string_vector.end(), int_vector.end(), make_zip_iterator( make_tuple( string_vector1.end(), string_vector2.end(), string_vector3.end() ) ) ) ), back_inserter(result) ); When I qualify the call to 'make_tuple' as 'boost::make_tuple' I don't see the error mentioned above, but I run into the conversion problem between a boost::tuple and an std::tr1::tuple. Any ideas how I can get around this? -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Quoting Dean Michael Berris <mikhailberis@gmail.com>:
Has anybody successfully used Boost.Iterator's zip_iterator with TR1 tuples from GCC's libstdc++?
I keep getting errors like "error: no type named 'head_type' in 'class std::tr1::tuple<..." when using TR1 tuples with the zip_iterator implementation in Boost 1.35.0 -- am I missing something?
The implementation of zip_iterator depends on the implementation of (boost::)tuple. The authors of zip_iterator were aware this was sub-optimal and specifially put all tuple-implementation-specific code in a namespace inside the detail namespace to aid future changes. The code is fairly old though.. it would be interesting to know if the tuple concept is now mature enough to admit a generic implementation.
on Tue Dec 09 2008, Peter Bartlett <pete-AT-pcbartlett.com> wrote:
Quoting Dean Michael Berris <mikhailberis@gmail.com>:
Has anybody successfully used Boost.Iterator's zip_iterator with TR1 tuples from GCC's libstdc++?
I keep getting errors like "error: no type named 'head_type' in 'class std::tr1::tuple<..." when using TR1 tuples with the zip_iterator implementation in Boost 1.35.0 -- am I missing something?
The implementation of zip_iterator depends on the implementation of (boost::)tuple. The authors of zip_iterator were aware this was sub-optimal and specifially put all tuple-implementation-specific code in a namespace inside the detail namespace to aid future changes. The code is fairly old though.. it would be interesting to know if the tuple concept is now mature enough to admit a generic implementation.
I have a fusion-based implementation checked in on a branch somewhere. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Tue Dec 09 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Tue Dec 09 2008, Peter Bartlett <pete-AT-pcbartlett.com> wrote:
Quoting Dean Michael Berris <mikhailberis@gmail.com>:
Has anybody successfully used Boost.Iterator's zip_iterator with TR1 tuples from GCC's libstdc++?
I keep getting errors like "error: no type named 'head_type' in 'class std::tr1::tuple<..." when using TR1 tuples with the zip_iterator implementation in Boost 1.35.0 -- am I missing something?
The implementation of zip_iterator depends on the implementation of (boost::)tuple. The authors of zip_iterator were aware this was sub-optimal and specifially put all tuple-implementation-specific code in a namespace inside the detail namespace to aid future changes. The code is fairly old though.. it would be interesting to know if the tuple concept is now mature enough to admit a generic implementation.
I have a fusion-based implementation checked in on a branch somewhere.
Here: http://svn.boost.org/svn/boost/branches/zip_iterator_fusion/boost/boost/iter... -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote on 10/12/2008 02:37:53:
on Tue Dec 09 2008, David Abrahams <dave-AT-boostpro.com> wrote:
on Tue Dec 09 2008, Peter Bartlett <pete-AT-pcbartlett.com> wrote:
Quoting Dean Michael Berris <mikhailberis@gmail.com>:
Has anybody successfully used Boost.Iterator's zip_iterator with TR1 tuples from GCC's libstdc++?
I keep getting errors like "error: no type named 'head_type' in 'class std::tr1::tuple<..." when using TR1 tuples with the zip_iterator implementation in Boost 1.35.0 -- am I missing something?
The implementation of zip_iterator depends on the implementation of (boost::)tuple. The authors of zip_iterator were aware this was sub-optimal and specifially put all tuple-implementation-specific code in a namespace inside the detail namespace to aid future changes. The code is fairly old though.. it would be interesting to know if the tuple concept is now mature enough to admit a generic implementation.
I have a fusion-based implementation checked in on a branch somewhere.
Here:
org/svn/boost/branches/zip_iterator_fusion/boost/boost/iterator/zip_iterator.
hpp
That's very helpful. Thank-you. -- Shayne Fletcher This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.
On Wed, Dec 10, 2008 at 1:37 AM, David Abrahams <dave@boostpro.com> wrote:
on Tue Dec 09 2008, David Abrahams <dave-AT-boostpro.com> wrote:
I have a fusion-based implementation checked in on a branch somewhere.
Here:
http://svn.boost.org/svn/boost/branches/zip_iterator_fusion/boost/boost/iter...
Thanks Dave, I'll give this a try. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris wrote:
On Wed, Dec 10, 2008 at 1:37 AM, David Abrahams <dave@boostpro.com> wrote:
on Tue Dec 09 2008, David Abrahams <dave-AT-boostpro.com> wrote:
I have a fusion-based implementation checked in on a branch somewhere. Here:
http://svn.boost.org/svn/boost/branches/zip_iterator_fusion/boost/boost/iter...
Thanks Dave, I'll give this a try.
It needs a little work for fusion still. While fusion is TR1 savvy, it thinks (through Boost TR1 [http://tinyurl.com/5awnzn]) that it *is* TR1. Not any other rendition of it. So, fusion needs to somehow detect which TR1 version you are using (Boost or gcc). In the case of Boost, nothing needs to be done. In the case of GCC's, fusion needs an adapter similar to that of fusion/boost_tuple adapter. Any suggestion on a better way to do the mapping/adapting appreciated. Adapting fusion to any other tuple-like entity is easy (Dean, you might want to give it a try, patch welcome). The tricky part is how to disable the one over the other on availability. Any thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote on 10/12/2008 13:19:34:
Dean Michael Berris wrote:
On Wed, Dec 10, 2008 at 1:37 AM, David Abrahams <dave@boostpro.com> wrote:
on Tue Dec 09 2008, David Abrahams <dave-AT-boostpro.com> wrote:
I have a fusion-based implementation checked in on a branch somewhere. Here:
org/svn/boost/branches/zip_iterator_fusion/boost/boost/iterator/zip_iterator.
hpp
Thanks Dave, I'll give this a try.
It needs a little work for fusion still. While fusion is TR1 savvy, it thinks (through Boost TR1 [http://tinyurl.com/5awnzn]) that it *is* TR1. Not any other rendition of it. So, fusion needs to somehow detect which TR1 version you are using (Boost or gcc). In the case of Boost, nothing needs to be done. In the case of GCC's, fusion needs an adapter similar to that of fusion/boost_tuple adapter.
Any suggestion on a better way to do the mapping/adapting appreciated. Adapting fusion to any other tuple-like entity is easy (Dean, you might want to give it a try, patch welcome). The tricky part is how to disable the one over the other on availability.
It should be also noted that Dave's program as posted will need a little work to be made compatible with the current state of fusion. It appears to have been based on a pre-review version. -- Shayne Fletcher This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.
Hi Joel, On Wed, Dec 10, 2008 at 12:19 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
Dean Michael Berris wrote:
On Wed, Dec 10, 2008 at 1:37 AM, David Abrahams <dave@boostpro.com> wrote:
Here:
http://svn.boost.org/svn/boost/branches/zip_iterator_fusion/boost/boost/iter...
Thanks Dave, I'll give this a try.
It needs a little work for fusion still. While fusion is TR1 savvy, it thinks (through Boost TR1 [http://tinyurl.com/5awnzn]) that it *is* TR1. Not any other rendition of it. So, fusion needs to somehow detect which TR1 version you are using (Boost or gcc). In the case of Boost, nothing needs to be done. In the case of GCC's, fusion needs an adapter similar to that of fusion/boost_tuple adapter.
I just took a look at Dave's code, and it does need a few things to get going with the current state of fusion in trunk. I'm trying to hack on it to make it work with the latest fusion and I see that it uses a function 'fusion::generate(...)'. I'm guessing that 'generate' is supposed to turn a view into a 'real' container, but somehow I'm not sure exactly what kind of container is required. I'm guessing it should be converted to make_tuple or make_vector, but I need to dig deeper to figure it out.
Any suggestion on a better way to do the mapping/adapting appreciated. Adapting fusion to any other tuple-like entity is easy (Dean, you might want to give it a try, patch welcome). The tricky part is how to disable the one over the other on availability.
Any thoughts?
About an adapter, it doesn't look like rocket science so I can try it out locally first to see if I can try adapting GCC's TR1 tuple to support tag dispatching on which fusion seems to depend on to "get things right". If only we can overload the assignment operator as a non-member function then this would all be a matter of defining (invalid at the moment): namespace { template <class T0, ... class TN> std::tr1::tuple<T0, ...TN> & operator=( std::tr1::tuple<T0, ... TN> & lhs, boost::fusion::tuple<T0, ... TN> && rhs ) { // assign the values from rhs to lhs // maybe using fusion::for_each return lhs; } template <class T0, ... class TN> std::tr1::tuple<T0, ...TN> & operator=( std::tr1::tuple<T0, ... TN> & lhs, boost::fusion::tuple<T0, ... TN> const & rhs ) { // assign the values from rhs to lhs // maybe using fusion::for_each return lhs; } } Wishful thinking I might think, but would definitely be a welcome addition to C++. Thanks again, and I hope to be able to make progress soon. (In the meantime I just moved away from GCC's TR1 tuple and stuck with Boost.Tuple ;) ). -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
on Wed Dec 10 2008, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
I just took a look at Dave's code, and it does need a few things to get going with the current state of fusion in trunk. I'm trying to hack on it to make it work with the latest fusion and I see that it uses a function 'fusion::generate(...)'. I'm guessing that 'generate' is supposed to turn a view into a 'real' container, but somehow I'm not sure exactly what kind of container is required. I'm guessing it should be converted to make_tuple or make_vector, but I need to dig deeper to figure it out.
I think that's called as_vector now. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Pete Bartlett wrote on 10/12/2008 01:45:51:
Quoting Dean Michael Berris <mikhailberis@gmail.com>:
Has anybody successfully used Boost.Iterator's zip_iterator with TR1 tuples from GCC's libstdc++?
I keep getting errors like "error: no type named 'head_type' in 'class std::tr1::tuple<..." when using TR1 tuples with the zip_iterator implementation in Boost 1.35.0 -- am I missing something?
The implementation of zip_iterator depends on the implementation of (boost::)tuple. The authors of zip_iterator were aware this was sub-optimal and specifially put all tuple-implementation-specific code in a namespace inside the detail namespace to aid future changes. The code is fairly old though.. it would be interesting to know if the tuple concept is now mature enough to admit a generic implementation.
It would be very nice if going forward, zip_iterator were to work with Boost.Fusion too. -- Shayne Fletcher This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.
participants (5)
-
David Abrahams -
Dean Michael Berris -
Joel de Guzman -
Peter Bartlett -
Shayne_Fletcher＠swissre.com