|
Boost : |
From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-12-19 19:23:20
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk