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

[David Abrahams]

Giulio Eulisse <giulio.eulisse at cern.ch> writes:

>> > 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.
>
> The problem is not the virtual function per se. It's the virtual
> function requiring QPopupMenu or so

What does "requiring" mean here?  Please try to use precise,
well-accepted terminology, or we will all be struggling to understand
you.  Do you mean that it accepts a QPopupMenu argument?  Surely the
argument is passed by pointer or reference if so (?)

> I don't have time, right now, to implement every single class in QT

When you say "implement" do you mean "wrap"?  The classes in QT are
surely already implemented (?)

> but I have to if these classes are in a pure virtual function. 

What does it mean for a class to be "in a pure virtual function"?
Do you mean that it is an argument or return type?

If I have translated all your terminology properly, then your premise
is wrong: as long as you don't need to override a pure virtual
function in Python (and I assume you don't because you're asking us
to give you an empty stub function) you don't need to wrap the
classes used as arguments.  In fact, you don't need to have wrapped
any classes until

    a. You want to wrap a derived class and use the base in bases<...>

    b. You want to actually convert an instance of the class to/from
       Python.

> PyQT just is much more advanced as for the number of classes
> implemented.

More advanced than what?

>> You must mean an abstract class.  There's no such thing as a virtual
>> class.
>
> Yes, sorry.
>
>> > which derives from a QT one, this class gets derived into
>> > "Derived"

A Python "Derived", I presume?

>> > 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&>.

OK, at that point, Base must have been wrapped.

>> 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.
>
> I get the "object" from the embedded python environment.

OK, then extract<Base&> is not used to pass it to C++; it's used once
the argument is already passed.

>> >  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.
>
> The problem is that if you exclude a pure virtual function(because you
> don't want to implement the whole QT), the code generated by pyste does
> not compile because the wrapping for that function is not generated.

OK, I understand that... but what's the point in excluding the pure
virtual function in the first place?  It doesn't cost you anything
until you try to call it, and then it will raise a Python exception,
as it should. There's no way that Pyste could in general figure out
how to give you a benign function body which does nothing, since it
doesn't know what a sensible return value is.  Even if the virtual
function returns void, it may be required by the Qt system to do
something in particular, and _not_ doing that could break Qt.

At this point I think I have a clue what problem you're trying to
solve, but my sense of it is that it's such a specialized need that
you should hack Pyste yourself to add the functionality you want,
because there's no way to implement it in a way that would be
generally useful to people.

>> I don't know the first thing about PyQt, but the real issue is that I
>> can't understand the problem you're having.
>
> I want to have a stripped down QT module and since QStyle has a pure
> virtual method which requires QPopupMenu, I want to exclude() it.
> I can't.

I still don't know what "requires" means here.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com