[C++-sig] make_constructor and BOOST_PYTHON_FUNCTION_OVERLOADS

[Jim Bosch]

On 02/02/2012 09:30 AM, Holger Brandsmeier wrote:
> Dear list,
>
> how can I combine make_constructor() and BOOST_PYTHON_FUNCTION_OVERLOADS()?
>
> I have a static member function in a class that "acts like a
> constructors", in the sense that it returns a shared pointer to the
> class. The function has default arguments, thats why I was thinking of
> using BOOST_PYTHON_FUNCTION_OVERLOADS.
>
> For usual member functions I've been using it like this:
> BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(Operator_apply, apply, 2, 5)
> [...]
>         .def("apply",&ClassT::apply, Operator_apply() )
>
> So for the constructor I thought probably I should use it like
> BOOST_PYTHON_FUNCTION_OVERLOADS(fPfemSpace_create, create, 2, 3)
> [...]
>            .def("__init__", make_constructor(&ClassT::create ),
> fPfemSpace_create())
>
> but that fails with the error:
> /usr/include/boost/python/class.hpp:598:37: error: no matching
> function for call to 'get_signature'
>              name, overloads, *this, detail::get_signature(sig));
>
> I tried out a few other variations for ".def(" but I didn't find the
> right one yet. Is there a way to combine make_constructor with
> BOOST_PYTHON_FUNCTION_OVERLOADS?
>

I've always used arg lists rather than the OVERLOADS macros to deal with 
default arguments, and I can confirm that those work with make_constructor:

bp::make_construct(&ClassT::create, bp::default_call_policies(),
                    (bp::arg("a"), bp::arg(b")=0))

The advantage is that your Python users get to use keyword args; the 
disadvantage is that you have to write them out (along with the default 
value).

I have noticed, however, that make_constructor isn't as flexible as 
make_function about the order of its own optional arguments - if you 
want to pass args, you also have to pass default_call_policies as the 
second argument, as I did above.  The same trick might work for the 
OVERLOADS macros, if you'd prefer to use those.


Jim