[Boost-users] [mpl][fusion] iteration over mutiple containers

Subject: [Boost-users] [mpl][fusion] iteration over mutiple containers
From: Manfred Doudar (manfred.doudar_at_[hidden])
Date: 2010-06-01 07:37:33

Hello,

I've been using the Boost.PP lately, and everything now works rather
nicely, but there's been a thing in the back of my head that has
always been telling me, that the problem is better suited to mpl/fusion.
The problem in this case is I have "two things" that need to be iterated
over, one a series of tags (aka "types"), and the the other, a runtime
index.

I'll express what I'm after with mpl::for_each, because the issue
becomes clearer that way:

  using namespace boost;

  //Func:  is an object that facilitates visitation on algorithms

  template <template <typename> Visitor>
  struct Func
  {
      typedef void result_type;

      template <typename R, typename A>
      result_type
      operator()(A* algo)
      {
           // do work.. visit algo, with Visitor<R>

           apply_visitor(std::move(Visitor<R>()), *algo, ...); 
      }
  }

  // tags are the return type on visitation
  typedef mpl::vector<int, float> tags;

  // container of algorithms
  Ctr<algorithms> ctr;

  Func<MyVisitor> ftor;
  mpl::for_each<tags>(bind(ref(ftor),
                           ::_1,              // [A]
                           ctr[INDEX])));     // [B]

[A]:  dispatch the tag
[B]:  pass through algorithm instance at INDEX.. I want to do INDEX++

Of course the problem here is that I can't update INDEX in each
mpl::for_each call, .. and thinking boost::fusion might be the
machinery I need, but I seemingly run into other problems with that
one too, there, since my tag-types are not of the same sequence as my
container of algorithms.

What I want is to pass in the appropriate tag, for each instance of
algorithm from a container.

Indeed, for those wondering, I have tried a typedef on each
algorithm, ..was hoping I could access the nested type A::type in place
of R in Func above, however, owing to the visitation mechanism, doing
so gives problems of access to incomplete-types elsewhere in the chain.

If anyone can suggest something, I'd be happy to hear it, ...as I said,
what I have already works, but I have a hard time letting this one
rest, knowing that there is a better alternative, but am not quite
seeing it yet.

Cheers,
-- 
Manfred