[PyKDE] sip: C++ virtual methods

[Jim Bublitz]

On Wednesday September 24 2003 10:04, Patrick Stinson wrote:
> in progression:

> Does the %ConvertToSubClassCode directive require some sort of
> class identification mechanism to be written into the original
> cpp library code? QEvent returns an enumerated value in
> type(), as well ass QApplication and some others, and QObject
> has QObject::className() that returns a string identifier.
> that can be used in conjuction with sipMapStringToClass() and
> a sipStringTypeClassMap struct.

> Does this mean I have to modify my cpp library to add some
> sort of class identifier for classs/subclasses if I want
> polymorphic return values in my python functions?

I had the same question, but unfortunately I posted it to Phil 
twice rather once to him and once to the list. Here's our 
exchange:



On Monday 22 September 2003 4:47 pm, you wrote:
> On Monday September 22 2003 02:03, Phil Thompson wrote:
> > > media = PK.CreateMediaLayer("./track.ogg")
> > > while not media.AtEnd():
> > >   media.Read()
> >
> > What do you get when you "print media"? If you get a
> > PK_MediaLayer instance then maybe you haven't implemented
> > %ConvertToSubClassCode properly.

===== my post =======

> From copying PyQt code, I understand (I think) how to implement
> %ConvertToSubClassCode for hierarchies like QObject or QEvent -
> but those both have methods that return some kind of type
> identifier (like QObject::className() ).
>
> If a hierarchy of classes *doesn't* have a method like that, 
> how do you do the %ConvertToSubClassCode block? Use the C++
> RTTI typeid() function?

> eg:

> class A {};
> class B : public A {};

> ---

> %HeaderCode
> #include <typeinfo>
> %End

> %ConvertToSubClassCode
>     static sipStringTypeClassMap map[] = {
>       {sipName_B, &sipClass_B},
>        ...
>     };

>     sipClass = sipMapStringToClass(
>          typeid (*sipCpp),
>          map, sizeof (map)/sizeof (map[0]));
> %End

> Would that work? I'm assuming sipCpp is already of the
> subclass'  type (or sipCpp->className () wouldn't work?), and
> this is just fixing the corresponding PyObject's type?

===== Phil's reply =======

There are potential problems there because the C++ instance might 
be "QObject"  or "sipQObject", but that's just a case of setting 
the table up properly. It  doesn't really matter how it is 
implemented, so long as a valid PyObject * is returned that is 
actually a Python class object.