|
Boost : |
From: rwgk_at_[hidden]
Date: 2000-12-11 21:29:47
> These functions should be defined by calling through the function
> pointers stored in the objects at x.X.__converters__.from_python and
> x.X.__converters__.to_python.
> No, you don't have to use PyCObjects; I would advise against it.
> I think I can implement the design I described in a previous message
> using your __converters__ idea. Does that fit the bill?
I am not sure if I am seeing the light here. Thinking out loud...
Is x.X.__converters__.from_python a Python reference to (or
callable Python function that returns?) a PyObject which is not
a PyCObject?
To get hold of that object, would you:
import x, getattr X, getattr __converters__, gettattr from_python?
Is the PyObject obtained in this way tailored to contain
a specific function pointer? Something like:
template <class T>
struct converter_shuttle : public PyObject {
PyObject *(*to_python)(const T&);
};
> I could show you how to use a class derived from class_builder in
> place of class_builder which does the export for you.
That would be terrific!
Thanks!
Ralf
P.S.: A few days ago I have been staring at your class_builder code
for
a few hours. I found myself as lost as I was a few years ago when I
was
trying to understand Fortran code full of arithmetic if statements.
It is impossible to understand any given little piece without having
at least 100 other little pieces in mind that are scattered all over
the place. I guess, the progress is that the spaghetti of dependencies
got orders of magnitudes more powerful. You can imagine how happy I
was when I discovered that all I really need is a couple of function
pointers that I could simply pass around as PyCObjects :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk