From: Alan W. I. <ir...@be...> - 2009-06-30 16:58:27
|
On 2009-06-28 20:49-0400 Hazen Babcock wrote: > Hazen Babcock wrote: >> >> Poking around a little more... >> >> In the function plD_line_qt we are not getting past this statement: >> >> #if defined(PLD_qtwidget) || defined(PLD_extqt) >> if(widget==NULL) widget=dynamic_cast<QtPLWidget*>((QWidget *) pls->dev); >> #endif >> if(widget==NULL) return; >> >> So the dynamic cast is not working for some reason? >> >> printf(" %ld %ld\n", (long)pls->dev, (long)widget); >> >> Suggests that pls->dev is valid, or at least not zero, but that widget >> is still zero after the cast. > > Hopefully someone can offer a few suggestions here... > > So far I have: > (1) The C++ QtExtWidget constructor is called when the corresponding > python object is created. > (2) The C++ QtExtWidget destructor is called when the program the ends. > (3) The address of the C++ QtExtWidget is not being moved on the Python > side. > (4) Introspection on the C++ side of the python object says that yes it > is a QtExtWidget object. eg. calling this function which I added to > plqt.cpp: > void plprintaddress(QtExtWidget* widget) > { > printf("PA %x\n", (long)widget); > std::cout << typeid(widget).name() << std::endl; > } > > Gives: > PA 1e0d3f0 > P11QtExtWidget > > (5) Forcing the cast (rather than using dynamic_cast) seems to make > things work (i.e.: widget = (QtPLWidget *)pls->dev;). > (6) Introspection in plD_line_qt like this: > std::cout << typeid(pls->dev).name() << std::endl; > Gives "Pv" as the type for both the Python originated QtExtWidget object > and the C++ originated object (by running the c++/qt_example program). > > So, any thoughts as to what might be causing the problem with dynamic_cast? Hi Hazen: I am just a rank newbie on non-C aspects of C++ like dynamic_cast, but I did (just) look up dynamic_cast, and it appears the casting conditions have to follow certain conditions from the object-oriented point of view before dynamic_cast works. You probably know all this stuff, but just in case, the discussion I found was at http://www.cplusplus.com/doc/tutorial/typecasting/. Its possible the code is violating one of those conditions, but I don't have the object-oriented expertise to figure out what that condition might be. There was mention also there of dynamic_cast not working if the wrong compiler flags having to do with RTTI are being used. But for g++, the default (-frtti) is correct. I also double-checked that -fno-rtti was not being used by mistake by inspecting "make VERBOSE=1" results for a complete build from scratch. There was no mention of rtti anywhere in those results so the (correct) default is being used unless the documentation is all wrong. Also, I double-checked that g++ (rather than gcc) was being used to compile and link qt.so (which contains all the dynamic casts in the now split qt code). So it appears the compilation and linking conditions are perfect. Another approach for debugging this issue is to look carefully at the qt_example.cpp code and also how it is compiled and linked since qt_example works perfectly right now. So you may want to investigate what is different about that code or how it is compiled and linked compared to the sip-generated code, sipAPIplplot_pyqt4.h, sipplplot_pyqt4QtExtWidget.cpp, sipplplot_pyqt4QtPLDriver.cpp, sipplplot_pyqt4QtPLWidget.cpp, and sipplplot_pyqt4cmodule.cpp in bindings/qt_gui/pyqt4 which is compiled and linked into the Python extension module, plplot_pyqt4.so? Another good possibility for figuring this out is you have stated your example used to work when you were ignoring the PLplot build system and simply using python to build plplot_pyqt4.so. If that really is the case, then by use of the svn checkout --revision argument you should be able to go back to exactly what we had before in an independent source code tree. If you confirm that old approach works, but the current approach based on the build system does not work, then that is an important clue to finding out what is wrong with the current approach and detailed comparisons of the old and new source trees and results should find the source of the problem. For example, did the old python-based approach to configuring and running sip produce the same sip-generated source code as the new CMake-based approach to configuring and running sip? I hope one or more of the above ideas will help you arrive at the needed breakthrough. I think your pyqt4 work is important so don't hesitate to get in touch with me off list if you need a (C++ naive, but CMake-smart and svn-smart) sounding board. Anyhow, I wish you the best in figuring out this issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |