>> I have some code that takes member function pointers of the form
>> R Obj::*( A1, A2, A3, ..., An )
>> and converts them to a function object Q with the following signature:
>> Rnew Q( Obj&, B1, B2, ..., Bn )
>> where
>> Rnew = result_conversion_metafunction<R>::type
>> Bi = arg_conversion_metafunction<Ai>::type
>> and Q is exposed via boost.python as a member of Obj.
>>
>> For example, Ai could be a fixed-point number, with Bi being a double so
>> that
>> the python side does not know anything about fixed-point numbers.
>
> I gather that custom converters aren't preferred because:
>
> 1. It is a hassle to talk directly to the underlying raw PyObject
> pointers and manage storage in the converter methods
>
> 2. The converted type still leaks out to python in docstrings
>
> Are there others? Or am I completely off?
Neither of the above is a big issue. In fact, python-side knowledge of the
converted type would even be mildly useful. The main problem is the number
of types:
my_fixed_point_type< int bit_width, // 1 to 63
int binary_pt_location, // -63 to 63
bool signed,
property_tag // policies for rounding, etc.
>
std::complex< my_fixed_point_type<...> >
boost::numeric::ublas::array< ... >
boost::numeric::ublas::matrix< ... >
There are simply far too many types to create converters for and to
register explicitly. Therefore, I use inline functions/functors to do all
the conversions on the C++ side, and python knows only about real and
complex doubles.
> > An instance
>> of Q would convert eh floating point numbers passed from the python side
>> into
>> fixed-point numbers, call the member function, and convert the returned
>> value
>> to a double for use on the python side.
>>
>> For these "converters", metafunctions from boost.function_types are used
>> to
>> obtain the mpl::vector specifying result type and argument types.
>> Extending
>> the technique above to function objects which take Obj* as their first
>> argument, I have a protocol which relies on the presence of a typedef
>> called
>> 'components' in the function object so that I can use the converter when
>> exposing via boost.python:
>>
>> struct my_functor {
>> typedef mpl::vector<R, Obj*, A1, A2, A3, A4> components;
>> R operator()( Obj*, A1, A2, A3, A4 ) { ... }
>> };
>
> To be sure I'm following you, correct me:
>
> * for each member function signature that you wrap, you have a matching
> my_functor that calls it
> * my_functor does nothing but call the member function it wraps
> * my_converter<my_functor>::type does the conversion from Rnew (B1, B2,
> ... Bn) to R (A1, A2, ...An) and calls my_functor.
>
> Have I got it?
Yes.
> It is all very interesting, and to a certain degree duplicates some
> functionality in detail/caller.hpp. How do you generate these
> my_functors... preprocessor? fusion?
Mostly boost.preprocessor (with some template metaprogramming using mpl).
Fusion doesn't work very well for me since the effort needed to get my
functors into a form usable from fusion is greater than just coding my own
invocation functions via boost.preprocessor; pseudo-code:
template <typename Func> struct my_converter
{
Func f_;
typedef typename ft::components<F>::type components;
typedef typename arg_converter<components>::type arg_types;
typedef typename result_converter<components>::type result_type;
// Shown for non-void return with one argument; can be generalized
// using enable_if for void types and using boost.preprocessor for
// different numbers of arguments
result_type operator()( typename at_c<1,arg_types>::type a1 )
{
return convert_result<result_type>( f_(
convert_arg<typename at_c<1,components>::type>( a1 ) ) );
}
};
template <typename Func>
my_converter<Func> make_converted_func( Func f )
{
return my_converter<Func>( f );
}
> I'm wondering if there isn't motivation here to cleanly integrate a
> general facility for additional c++-side type conversions. The
> following came to mind, which imitates a function type style that
> boost::proto uses extensively:
>
> struct hidden_type; // python shouldn't see this at all
>
> struct int_2_hidden // converts python-side 'int' to hidden
> {
> typedef hidden_type result_type;
>
> hidden_type operator()(int) const;
> };
>
> // fnobj takes a hidden, doesn't know it is wrapped in python
> struct fnobj {
> typedef void result_type;
> void operator()(float, hidden_type);
> };
>
> def("myfunctor", as<void(float, int_to_hidden(int))>(fnobj()));
>
> where int_to_hidden(int) is a function type (not a function call, but it
> later becomes a function call), indicating that what python passes
> should be converted to int, then the int converted to hidden_type via an
> instance of int_to_hidden, then the hidden_type passed to the underlying
> instance of fnobj.
>
> I realize this doesn't involve using the mpl::vectors you've already
> calculated, just throwing it out there.
Such a general facility would probably be better than my code and would be
greatly useful for me, but are there enough people out there with this use
case? I don't care about using mpl::vector if there is a more general
solution.
>> // my_converter uses the components typedef
>> typedef typename my_converter<my_functor>::type Q;
>
> so Q could have a nested typedef (note I say Rnew, not R):
>
> typedef mpl::vector<Rnew, Obj*, B1, B2, B3, B4> components;
>
> or use that in combination with function_types to synthesize
>
> typedef Rnew(Obj*, B1, B2, B3, B4) signature;
Yes.
Regards,
Ravi
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
