...

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