Re: [boost] [iterators] zip_iterator doesn't work with GCC's TR1 tuple?

Subject: Re: [boost] [iterators] zip_iterator doesn't work with GCC's TR1 tuple?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-12-10 02:21:12

Hi Joel,

On Wed, Dec 10, 2008 at 12:19 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>>
>> On Wed, Dec 10, 2008 at 1:37 AM, David Abrahams <dave_at_[hidden]> wrote:
>>>
>>> Here:
>>>
>>>
>>>  http://svn.boost.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.
>

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.