[C++-sig] pyste and virtual classes.

Nicodemus nicodemus at globalite.com.br
Mon Mar 31 22:23:51 CEST 2003


David Abrahams wrote:

>Giulio Eulisse <giulio.eulisse at cern.ch> writes:
>
>
>>>I can understand that, but I am having a hard time understanding what
>>>the use-case for such an arrangement is.  The C++ class designer
>>>explicitly said "you can't instantiate a class unless you implement
>>>this function".  Now you want to subvert that, in some sense.  Is the
>>>result really useful?
>>>
>>I understand what you mean and I would generally agree with what you
>>say.
>>The point is that in my case I cannot modify the library in question
>>(QT) and at the same time I would like to have a working (although very
>>limited) python module to see if what I want to do works or not.
>>Because of the complexity of QT I have to remove some pure virtual
>>methods because otherwise I would end up implementing bindings for the
>>whole library.
>>
>
>OK.
>
>
>>So I'm not saying that it would be really useful or a good coding
>>practice but, at least for me, it would be nice to have, for prototyping
>>and experimenting, just like the "exclude all that contains xyz"
>>feature.
>>
>
>I understand what you're asking for, but I can't for the life of me
>understand why you need it.  See ** below.
>
>
>>Another possible solution would be get rid of the whole boost/QT idea,
>>and make PyQT and boost play nicely together
>>
>
>It's not clear that PyQT (SIP) will automatically generate empty
>virtual functions for you either.
>
>
>>(and play nicely with an existing QApplication object). The problem
>>is that I have to do the following:
>>
>>I have a virtual class "Base", 
>>
>
>You must mean an abstract class.  There's no such thing as a virtual
>class.
>
>
>>which derives from a QT one, this class gets derived into "Derived"
>>and extended in python. An instance of the class "Derived" is
>>created in an embedded python environment and is passed to C++ using
>>something like extract<Base&>.
>>
>
>It's not clear what you mean by "passed to C++ using
>extract<Base&>".  You can only write extract<Base&> in C++, so the
>object must already be available in C++ code somehow.
>
>
>> The virtual method MyBase.method() is then called in C++ and its
>>python implementation in Derived gets called.
>>
>
>**OK so far; I don't see any need to provide a C++ implementation of
>the virtual member function other than the one provided automatically
>by pyste's generated wrapper class.  That alone should be enough to
>ensure that there is no problem with instantiating an abstract base
>class.
>
>
>>Both the C++ and the Python environment need to access the
>>QT part of the class, and I don't want (better: I have not to) to
>>write wrappers around all the QT functions I need. I haven't figured
>>out how to do the extract<Base&> part when using PyQt. Maybe you can
>>help me?
>>
>
>I don't know the first thing about PyQt, but the real issue is that I
>can't understand the problem you're having.
>

But Giulio, what's the problem in exporting all virtual functions? I 
assume you have something like:

struct A
{
    virtual C getC();
};

and you don't want to export the class C, right? But remember that 
exporting class A without class C will compile just fine. If you try to 
call getC in Python, you will just get an exception. Was that the 
problem, or I misunderstood?

Regards,
Nicodemus.






More information about the Cplusplus-sig mailing list