Ravi wrote:

On Sunday 11 October 2009 19:44:29 troy d. straszheim wrote:

...

...

Why is the overloaded get_signature not picked up when it is declared after the inclusion of the headers? I'm not sure why it isn't picked up.

Does that mean that you can reproduce the problem I pointed out?

Yes I can.

...

I've been working in this area, replacing most of detail/caller.hpp and detail/invoke.hpp with boost.fusion, seen here:

http://gitorious.org/~straszheim/boost/straszheim/blobs/python/boost/python /detail/caller.hpp

In the process, I overhauled get_signature to use boost::function_types, and to be a metafunction, not a function:

http://gitorious.org/~straszheim/boost/straszheim/blobs/python/boost/python /signature.hpp

IMHO, this is the right way to do it. This avoids relying on the compiler to optimize out all the ugly tag-dispatching. Of course, Dave A & Ralf WGK did not have function types when they wrote this originally.

Yes, the code was all dated ~2002. There are more corners of the code that could use modernization as well.

[snip]

...

boost::function<int(X*, int)> bf0(fobj);

Why do you need to use boost::function here? Shouldn't the type be deduced automatically?

Note that the .def() of the various boost::function objects work without requiring the user to specialize get_signature, (since this modified get_signature metafunction knows about boost::function objects). Here's a different (working) example: #include <boost/function.hpp> #include <boost/lexical_cast.hpp> #include <boost/python.hpp> #include <boost/python/class.hpp> #include <boost/python/module.hpp> struct X { int y; }; struct add_to { template <typename T> T operator()(X* x, T t) const { return t + x->y; } std::string operator()(X* x, std::string s) { return s + boost::lexical_cast<std::string>(x->y); } }; using namespace boost::python; BOOST_PYTHON_MODULE( function_objects_ext ) { add_to add_to_inst; boost::function<int(X*, int)> f_int(add_to_inst); boost::function<std::string(X*, std::string)> f_string(add_to_inst); boost::python::class_<X>( "X" ) .def_readwrite( "y", &X::y ) .def( "add_to", f_int) .def( "add_to", f_string) ; }

...

...

from function_objects_ext import * x = X() x.y = 13 x.add_to(1) 14 x.add_to("foo") 'foo13'

Some musings: I think interoperability with boost::function is a Good Thing, but in the example above (and the previous), all it does is give def() a way to tell what the signature of the function object is at compile time, and it does so at a runtime cost. A specialization of get_signature works, but strikes me as kinda ugly (it should at least be moved out of 'detail' if it is a user customization point). How about something like class_<T>("T") .def("f1", f1, sig<void(T*, double)>) .def<void(T*, double)>("fi", f1) Which looks pretty straightforward when dealing with function objects, but when dealing with overloads, things get tricky: void f2(T*, int); void f2(T*, double); class_<T>("T") .def("f2", f2) // #1 error .def("f2", (void(*)(T*, int))f2) // #2 ok but ugly .def<void(T*, int)>("f2", f2) // #3 works but tricky ; #1 is an error, because f2's type is undetermined. #2 is how you can fix #1 in current practice (or with an alias). #3 could work (I've tried, it works) if def, when passed a function type, only accepts pointers to functions of that type, so that the overload is resolved. But how to use this same form to also specify the types of arbitrary function objects... haven't thought about that yet.

...

I'm fairly new to the internals of boost.python, and only just now got this working... Do you see problems with this, specifically the conversion of get_signature from function to metafunction?

I don't see any problems with the conversion of get_signature to a metafunction. Do compile times get any longer?

I haven't checked this yet. I have other concerns re typechecking and automatic conversions... I'll go back and look more closely. -t

Ravi wrote:

I'd rather have something along the lines of .def< mpl::vector<void,T*,double> >("f1",f1)

I have something working. There is still a bunch of stuff to iron out yet. I went with def("name", as<Signature>(callable)); where Signature is the signature with which callable will be called, e.g. struct times_seven { template <typename T> struct result; template <typename Self, typename T> struct result<Self(T&)> // annoying: reference { typedef T type; }; template <typename T> T operator()(const T& t) { return t * 7; } }; BOOST_PYTHON_MODULE( function_objects3_ext ) { def("times_seven", as<int(int)>(times_seven())); } the T& in the struct result is something I haven't yet sorted out, has something to do with how I am constructing fusion sequences from the converted python objects before calling fusion::invoke. Anyhow, it works:

...

...

times_seven(7) 49

I thought that one might try to remove the necessity of having the return type in the Signature and/or implementing the result_of protocol, but maybe it is nice that they don't have to match: def("times_seven", as<double(int)>(times_seven()));

...

...

times_seven(7) 49.0

boost::function still works, and doesn't require as<>: boost::function<int(int, int)> myplus = std::plus<int>(); def("myplus", myplus); and old-school function objects: def("otherplus", std::plus<int>()) I was surprised to find that it all plays nice with boost::phoenix: def("plus", as<int(int, int)>(arg1 + arg2)); def("throw_if_gt_5", as<void(int)>(if_(arg1 > 5) [ throw_(std::runtime_error("too big!!")) ] .else_ [ std::cout << val("okay") ])); And boost::phoenix plays nice with shared_ptr, which plays nice with boost::python: struct X { int x; }; typedef boost::shared_ptr<X> XPtr; class_<X, XPtr>("X") .def_readwrite("x", &X::x) .def("add7", as<void(X*)> (arg1->*&X::x += 7)) .def("add8", as<void(XPtr)>(arg1->*&X::x += 8)) .def("add9", as<void(X&)> (bind(&X::x, arg1) += 9)) ; the other little thing is overload resolution, for which I propose a little helper function "unload" (underload? deload? resolve? I dunno): void foo(int); void foo(double); def("foo", unload<void(int)>(foo)); Which is safer than def("foo", (void(*)(int)) foo); and just as safe as, and less verbose than void(*fooint)(int) = foo; def("foo", fooint); So that's where I'm at... what do you make of that interface? -t

Ravi wrote:

On Wednesday 14 October 2009 21:59:42 troy d. straszheim wrote:

...

def("plus", as<int(int, int)>(arg1 + arg2));

This is very cool and pretty intuitive. My main concern is that one needs to build up the function type in generic code (as opposed to mpl vectors), but we do have function_types to help us.

I take it that you have a use-case where it is difficult to specify as<R(A1,A2)>(thing) and easy to specify as<mpl::vector<R, A1, A2> >(thing) Could you elaborate? I'm quite sure there is a way to provide (roughly) both interfaces: def("foo", as<int(double, string)>(functor())); def("foo", as<mpl::vector<int, double, std::string> >(functor())); but I'm not sure I understand the problem.

You are going to have to propose this as several small patched, before Ralf & Dave agree to it.

Shit. I knew this would happen, I've written too much code again. Dave? Ralf? -t

Ravi wrote:

On Saturday 31 October 2009 01:24:16 troy d. straszheim wrote:

...

I take it that you have a use-case where it is difficult to specify

as<R(A1,A2)>(thing)

and easy to specify

as<mpl::vector<R, A1, A2> >(thing)

Could you elaborate?

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 (Both effects are visible in the custom string example: http://www.boost.org/doc/libs/1_40_0/libs/python/doc/v2/faq.html#custom_stri...) Are there others? Or am I completely off?

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? 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? 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.

// 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;

Q q; class_<Obj,...>( "Obj" ) .def( "my_func", q ) ;

-t