Re: [Boost-users] [fusion] proposal BOOST_FUSION_ADAPT_FUNCTION, BOOST_FUSION_DEFINE_FUNCTION, etc

Subject: Re: [Boost-users] [fusion] proposal BOOST_FUSION_ADAPT_FUNCTION, BOOST_FUSION_DEFINE_FUNCTION, etc
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-10-15 02:51:37

On Fri, Oct 15, 2010 at 12:00 AM, alfC <alfredo.correa_at_[hidden]> wrote:
>
>
> On Oct 14, 10:45Â pm, OvermindDL1 <overmind..._at_[hidden]> wrote:
>> On Thu, Oct 14, 2010 at 11:41 PM, alfC <alfredo.cor..._at_[hidden]> wrote:
>>
>> > On Oct 14, 10:30Â pm, OvermindDL1 <overmind..._at_[hidden]> wrote:
>> >> On Thu, Oct 14, 2010 at 11:09 PM, alfC <alfredo.cor..._at_[hidden]> wrote:
>> >> > Hi,
>>
>> >> > Â I am using Boost.Fusion lately. Sometimes one has a function with
>> >> > several parameters,
>>
>> >> > int f(double d , int i , std::string s){
>> >> > Â ...bla bla ...
>> >> > }
>>
>> >> > the logic of the program says that sometimes that same funcion will be
>> >> > called by generic code and in such case it is better if "f" where
>> >> > defined as taking a fusion::vector as argument.
>>
>> >> > int f(fusion::vector<double, int, std::string>) // another function,
>> >> > could be an overload even
>>
>> >> > since there is only one why to define this adaptor function, e.g.
>> >> > int f(fusion::vector<double, int, std::string> x){
>> >> > Â return f(at_c<0>(x), at_c<1>(x), at_c<2>(x));\
>> >> > }
>>
>> >> > and it is pretty mechanical. I was wondering if it would be a good
>> >> > idea to have, with consistency with the  BOOST_FUSION_ADAPT_STRUCT,
>> >> > something called BOOST_FUSION_ADAPT_FUNCTION
>>
>> >> > BOOST_FUSION_ADAPT_FUNCTION(
>> >> > Â  Â int, f,
>> >> > Â  Â double,
>> >> > Â  Â int,
>> >> > Â  Â std::string
>> >> > )
>> >> > (or something like that)
>> >> > that defines the second / fusion-compatible version of f.
>>
>> >> > It could be even a
>>
>> >> > BOOST_FUSION_DEFINE_FUNCTION(
>> >> > Â  Â int, f,
>> >> > Â  Â (double, d),
>> >> > Â  Â (int, i),
>> >> > Â  Â (std::string, s),
>> >> > Â  Â ( ... code using variables d, i, s or at_key<d_>, at_key<i_>,
>> >> > at_key<s_> ... Â )
>> >> > )
>>
>> >> > that defines simultaneously the raw-C function, f(double, int, string)
>> >> > *and* the fusion friendly version f(vector<...>).
>> >> > I could probably program these macro for specific cases but not a
>> >> > general one since I don't know enough macro syntax to make it work.
>>
>> >> > Do you think it is a good idea or it is already doable with existing
>> >> > Fusion features?
>>
>> >> It should already be doable, given example:
>> >> Â  // include fusion here
>>
>> >> Â  int f(double d , int i , std::string s){
>> >> Â  Â  ...bla bla ...
>> >> Â  }
>>
>> >> Â  int main(void) {
>> >> Â  Â  boost::fusion::vector<double,int,std::string myVec(3.14, 42,
>> >> "Hello World!");
>> >> Â  Â  return boost::fusion::invoke(&f, myVec);
>> >> Â  }
>>
>> > cool.
>> > one question: Â does it work for member functions as well?
>>
>> It works for any thing that fulfills the Boost.Fusion callable concept
>> as outlined here:
>> Â http://www.boost.org/doc/libs/1_44_0/libs/fusion/doc/html/fusion/func...
>>
>> So yes, it works for member functions (where the class instance it is
>> called from is the ***first entry in the fusion vector/list/whatever).****
>
> that "first entry" feature is an annoyance for my application.
>
> I have mostly function objects
>
> class f_impl{
> Â double operator()( double, int, string ...);
> }
>
> f_impl f;
>
> for which I would like to have a systematic way of
> using it as
>
> f( vector<double, int, string, ... > )
>
> without having to add the f_impl at the beginning of the
> fusion::vector

Do note, on the deferred callable concept page, boot::bind fills the
concept, so if you either do not want to pass the class as the first
value, or if you want to bind to an instance of a member function,
just give it boost::bind(&myclass::myFunc, myClassInstPtr, _1, _2,
..., _n) instead,, but in this case you will always operate on that
one instance.

Do note that functors (make sure it implements the boost::result_of
concept too) can be passed as-is just by constructing one (like f() in
your above example) to the fuser and it should 'just work', no needing
to pass an instance to it as it uses operator() of the instance.