Alan W. Irwin wrote:
> 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.
>
Hi Hazen, Alan,
You cannot use dynamic_cast to convert the void pointer pls->dev to a
QtPLWidget pointer.
The purpose of dynamic_cast is to do a safe (runtime checked) cast
from a base class to a derived class or vice-versa. As QtPLWidget is
not derived from void the cast fails.
For your code you have to use C++ reinterpret_cast or a C style cast.
Kind regards
Terrence
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
