Re: [boost] Boost.Python def and member function overloads

Subject: Re: [boost] Boost.Python def and member function overloads
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2009-05-05 07:10:35

Matt Calabrese wrote:

> I attended Troy Straszheim's Icefishing for Neutrinos Boostcon session
> today, which was a great talk on Boost.Serialization and Boost.Python in
> a very interesting context. I have not worked with Boost.Python in
> practice, having only skimmed the documentation, but was amazed at just
> how powerful and easy to use it is.
> 
> However, in his examples, he included exposing classes from C++ that have
> member functions with multiple overloads and noted that it is somewhat
> cumbersome due to the fact that you have to explicitly cast your member
> function pointers when calling .def. For a type "your_type" with a member
> function "foo" having two overloads, one that takes an int, and another
> that takes an int and a float, the current syntax comes down to something
> along the lines of:
> 
> /*class_ specification here */
> .def( "foo", static_cast< void (your_type::*)(int) >(&your_type::foo))
> .def( "foo", static_cast< void (your_type::*)(int, float)
>>(&your_type::foo))
> ;
> 
> Disambiguation is obviously necessary here, but I wonder if it could be
> handled in a much simpler way such as to avoid explicitly casting or even
> the explicit use of member function pointer types at all. I propose doing
> this by allowing users to explicitly pass in a non-member function type as
> a template argument to def, using a metafunction to translate that type
> to the appropriate member function type, and having that calculated type
> be the 2nd parameter type of the function. The suggested syntax would be
> something along the lines of:
> 
> /*class_ specification here */
> .def< void(int) >( "foo", &your_type::foo )
> .def< void(int,float) >( "foo", &your_type::foo )
> ;
> 
> which I feel would be a significant simplification of use and should not
> be difficult at all to implement (just detect if the first template
> argument to def
> is a function type and if so do the appropriate transformation to
> yield the 2nd function
> parameter type, otherwise have it work like existing definitions). Would
> this be a feature that people find useful and be worth pursuing?
> 

I like it!  I hope it's feasible.