Re: [boost] fusion and forwarding problem

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2006-12-20 04:47:33

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
>