Thank you for the quick response!
On Thu, 18 Apr 2013 15:24:09 +0100, Jim Bosch <tallji...@gmail.com> wrote:
If you go with writing your own PyTypeObject, you will indeed have a lot more control, but it will greatly limit how much Boost.Python you can use (no class_, for instance, at least), and you'll need to dive deep into the Boost.Python implementation to learn how and when you can use it. I'd only consider recommending this approach if you wanted to wrap one or two simple classes this way and then use regular Boost.Python for everything else.
No class_<..> type would be a problem, as I've already exposed a lot of its derived classes this way.. There's got to be about 100 in total. :-\
I think the best solution would probably be to use shared_ptr with a custom deleter, as that gives you control over how your objects are allocated while giving Boost.Python an object it knows how to handle extremely well. One key ingredient of this is that instead of wrapping C++ constructors, you'll want to wrap factory functions that return shared_ptrs. You can even wrap such functions as Python constructors using make_constructor.
I've already had to do this once, so I've got some experience with the technique, although can't remember exactly why it was needed. Thank you for a viable option, though!
All that said, my first recommendation would be to try to wrap it (or at least a subset of it) without trying to get the optimal memory performance first, and only fix it if it actually is a performance problem. You might be surprised at where the time ends up going.
:) Lol, yes, I can see how attempting to define a new PyTypeObject could become very time-consuming!
If I were to go this route though (I probably will), is there a Boost Python registry or something where I can register these new types? I just thought to look into list.hpp, as I figure the boost::python::list would probably make use of the PyListType, which could be thought of as a similar PyTypeObject specialisation to one I might like to create.
......
Now I've done a little more digging, I think I have an idea of how to do it, which I'll detail now.. Any tips, pointers or advice in Boost::Python'ising it would be appreciated, as I have next to no experience with the Python-C API beyond Boost.
Resources
---------
Worth mentioning that the best (simplest) resources I've found to go by, are:
[1] - For the C-Python side: http://docs.python.org/2/extending/newtypes.html
[2] - For Boost-Python side: http://www.boost.org/doc/libs/1_53_0/boost/python/list.hpp
Steps to expose:-
-----------------
a. - Create mytypeobject.h, a raw C-Python extension type, as explained in [1].
a.i. - Create unit-test, by deriving such a type in Python, making a
few instances, deleting some and leaving others to the garbage
collector.
b. Create mytypeobject.hpp, where a type similar to boost::python::list is declared. Register it, with for example:-
// From list.hpp:-
//
namespace converter
{
template <>
struct object_manager_traits<list>
: pytype_object_manager_traits<&PyList_Type,list>
{
};
}
What else?
----------
I very much doubt it will be this simple, as any exposed class_<> would probably still attach a typical PyObject, thereby using PyTypeObject's memory management functions, rather than that of any type object specialisation.
Example
-------
For example, let's suppose PyListObject has some functionality I need in an exposed class, and I need the garbage collector to use PyListType instead of PyTypeObject, when managing its memory.
Is there a way to attach a PyListObject to a class_<> instance, instead of a PyObject? Perhaps an alternative to the class_<> template could be designed to use any arbitrary type, instead of the default PyTypeObject. Something which could be used like this would be cool:-
boost::python::type_object_<PyListType, PyList, [boost::noncopyable]>
("alt_list", "PyListObject wrapped in Boost.",
init<>())
.def("append", PyList_Append)
/// ...
;
How much farther do you think I would need to dig into Boost internals to implement such functionality? Worth it?
Cheers,
Alex
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
