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
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
