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.