Re: [boost] fusion and forwarding problem

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2006-12-20 18:23:45

Please ignore my last post, I finally understood the meaning of what you
have written. My problem is of more simple nature, so I was a bit lost in my
own thoughts here..

I would be very interested in using your extension.

Regards,
Christian

On 20/12/06, Christian Holmquist <c.holmquist_at_[hidden]> wrote:
>
> Tobias,
> Thanks you for the reply on this matter.
>
> Is your code available in the Boost Vault for download, and some example
> using it?
>
> > There would be multiple variants of these class templates with different
> properties of the call operator:
> >
> >    - only accepting lvalues (like make_<seq>)
> >    - only accepting rvalues (like <seq>_tie)
> >    - only accepting predefined types (like <seq>'s ctor, this one would
> have
> >      another template parameter)
> >    - accepting any combination of lvalues and rvalues (exploding all 2^N
> >      possibilities - a brute force solution to the forwarding problem,
> >      until we have better ways to solve it)
>
> I don't understand your reason for the lvalues/rvalues explotion. The
> distinct type is available in the fusion sequence, why overload completely
> unspecified types? (if that's what you do?).
> Given the sequence<int, int&, const int&> I would expect the overload to
> be (ignoring return type here) void operator()(int, int&, const int&).
> The utility I wrote solves this with
>
> void operator()
> (
> typename fusion::result_of::value_at_c<Sequence, 0>::type,
> typename fusion::result_of::value_at_c<Sequence, 1>::type,
> typename fusion::result_of::value_at_c<Sequence, 2>::type
> )
>
> I assume I've oversimplified the issue, so what aspect am I missing here?
>
> Thanks,
> Christian
>
> On 20/12/06, Tobias Schwinger < tschwinger_at_[hidden]> wrote:
> >
> > Hi Christian,
> >
> > Christian Holmquist wrote:
> > > Ok, so to my humble problem. I'm constantly finding myself writing
> > those
> > > overloaded functions like:
> > >
> > > ------------------
> > > template<class A0, class A1, ....>
> > > void operator()(const A0& a0, const A1& a1, ...) const
> > > {
> > > do_something_very_clever(fusion_sequence_type(a0, a1, ...));
> > > }
> > > ------------------
> > >
> > > This is cumbersome and boring, and usually I just add the overloads
> > when
> > > someone else needs it.. It's not always the case I can know beforehand
> > to
> > > overload const T& or just T& also, but it depends on the use case.
> > >
> >
> > I mentioned this case in my review and already spent some time on
> > implementing a solution. The second rewrite didn't satisfy me, so here's are
> > the design sketches for the next attempt:
> >
> > A set of class templates with (at least) the following template
> > parameters:
> >
> > 1. An unary (Fusion-) function object
> > 2. Some way to specifiy the sequence implementation
> > 3. Constraints that apply to the arguments of the (overloaded)
> > call-operator
> >
> > The function object would describe a finalizing transform and do
> > whatever you want to get done.
> > The sequence implementation should be parametrized, to share the
> > (possibly lengthy, see below) code.
> > The constraints would be needed to specify things such as min/max arity
> > or required argument types / conversion properties (some compile time
> > functional, such as an MPL lambda expression would probably be the most
> > flexibile). They're also needed to control early instantiation of the
> > "empty-sequence path" (nullary operator() isn't lazy, because it can't be a
> > template).
> >
> > There would be multiple variants of these class templates with different
> > properties of the call operator:
> >
> >    - only accepting lvalues (like make_<seq>)
> >    - only accepting rvalues (like <seq>_tie)
> >    - only accepting predefined types (like <seq>'s ctor, this one would
> > have
> >      another template parameter)
> >    - accepting any combination of lvalues and rvalues (exploding all 2^N
> >      possibilities - a brute force solution to the forwarding problem,
> >      until we have better ways to solve it)
> >
> > Note that 'make_<seq>' and '<seq>_tie' function could be implemented as
> > global instance variables of the (appropriately configured) templates for
> > the first two cases (the former with a copy and the latter with an identity
> > function, both unrestricted).
> >
> > I don't want to have to do a fourth rewrite, so comments are very much
> > welcome.
> >
> > Regards,
> >
> > Tobias
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>