How do I wrap virtual methods (solved)
Hi all, I changed the wrapping approach to the wrapper<...>, and with some ajustments it worked. I will display the code (just the essential part) below: struct QObject_Wrapper: QObject, wrapper<QObject> { // notice that I have overloaded constructors // so I have to redefine them QObject_Wrapper(): QObject() { } QObject_Wrapper(QObject* parent): QObject(parent) { } bool event(QEvent* p0) { if (override event = this->get_override("event")) { // here is the trick. "event" is a Python object // not a real C++ funcion return event( ptr( p0 ) ); } return QObject::event(p0); } bool default_event(QEvent* p0) { return this->QObject::event(p0); } }; void export_QObject() { class_<QObject_Wrapper, boost::shared_ptr<QObject_Wrapper>, boost::noncopyable> ("QObject") // constructor with no parent .def(init<>()) // constructor with QObject parent .def(init<QObject*>( args("parent") ) [with_custodian_and_ward<1,2>()] ) .def("event", &QObject::event, &QObject_Wrapper::default_event) ; } So, it solved the problem. The only thing that I am concerned about, is how does it know to convert native "QObject" to the "QObject_Wrapper". Well its working well anyway. BTW, Pyste must be updated for that wrapper<...> use. Thanks everybody. I am enjoying Boost.Python more everyday :) [Eric Jardim]
Eric Jardim <ericjardim@gmail.com> writes:
The only thing that I am concerned about, is how does it know to convert native "QObject" to the "QObject_Wrapper".
It doesn't. QObject_Wrapper is only needed when the virtual function might be overridden in Python. By the time you have a native QObject, all of its class' virtual functions are already determined. -- Dave Abrahams Boost Consulting www.boost-consulting.com
2005/8/5, David Abrahams <dave@boost-consulting.com>:
It doesn't. QObject_Wrapper is only needed when the virtual function might be overridden in Python. By the time you have a native QObject, all of its class' virtual functions are already determined.
Sure, but how does Boost.Python knows that I am exposing QObject? I am exposing a derived class of it (QObject_wrapper). Someway, it knows that, implicitly, QObject must me exposed too. I created a function for test this: QObject* factory(QObject* parent) { return new QObject(parent); } And later: def("factory", factory, return_value_policy<manage_new_object, with_custodian_and_ward_postcall<0,1> >()); But how does it will manage this, is I am holding shared pointer to an QObject_Wrapper? class_<QObject_Wrapper, boost::shared_ptr<QObject_Wrapper>, boost::noncopyable> ("QObject") I tried to change the pointer to a boost::shared_ptr<QObject> but it did't worked. But somehow, it is working with the wrapper pointer. There may be some "magic" behing the templates :) And the good news is that there is no need to create the QCustomObject class :) Thanks again, [Eric Jardim] Boost.Python new fan!
Eric Jardim <ericjardim@gmail.com> writes:
2005/8/5, David Abrahams <dave@boost-consulting.com>:
It doesn't. QObject_Wrapper is only needed when the virtual function might be overridden in Python. By the time you have a native QObject, all of its class' virtual functions are already determined.
Sure, but how does Boost.Python knows that I am exposing QObject? I am exposing a derived class of it (QObject_wrapper). Someway, it knows that, implicitly, QObject must me exposed too.
It knows that QObject_wrapper is derived from wrapper<QObject>. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Eric Jardim