|
Boost Users : |
Subject: Re: [Boost-users] [fusion?] [Phoenix?] Calling arbitrary method with collection of args
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-03-22 00:37:28
On Fri, Mar 19, 2010 at 11:24 AM, Nat Goodspeed <nat_at_[hidden]> wrote:
> Kim Kuen Tang wrote:
>
>> Nat Goodspeed schrieb:
>>>
>>> I'm a bit surprised not to find existing support for std::vector;
>>> presumably that's been done a few times by individuals.
>>
>> The size of std:::vector is not an mpl integral constant ( not known in
>> compile time). So std::vector is not a sequence in the sense of fusion. See
>>
>> http://boost-spirit.com/dl_more/fusion_v2/libs/fusion/doc/html/fusion/sequence/concepts/forward_sequence.html
>
> Then maybe boost::fusion::invoke() isn't what I'm looking for.
>
> Nonetheless it comes frustratingly close: the preprocessor iteration to
> handle various arities is already done.
>
> (In fact handling some number of C++ arities is (re)implemented in a
> surprising number of different Boost libraries.)
>
> Presumably Boost.Python has internal machinery very like what I want,
> receiving an arbitrary sequence of Python variant objects and using them to
> populate the parameter list of some C++ callable. Of course I don't want to
> start basing production code on an undocumented implementation detail,
> though.
>
> Still looking for a Boost feature to apply (e.g.) a std::vector of parameter
> values to a C++ callable... thanks for additional suggestions.
Actually I have done that same kind of thing as what you are wanting
with my RPC library using Boost::Fusion. Statically you build up a
recursive functor that creates the fusion sequence that matches the
function, and dynamically you populate it with the vector elements and
invoke it (or throw an exception if you have too many or too few
vector elements?). It is actually quite easy and Boost has an example
of that in the boost::function_types examples.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net