Re: [pygccxml-development] questions about inheritance

[Roman Y. <rom...@gm...>]

On Sat, Mar 1, 2008 at 8:03 PM, Kevin Watters <kev...@gm...> wrote:
> Say I have
>
>  class A {
>  public:
>     virtual void DoSomething() = 0;
>  };
>
>  and
>
>  class B {
>  public:
>     void Something() { /* ... */ }
>     virtual void DoSomething() { Something(); }
>  };
>
>  I want to hide the DoSomething methods from Python, but keep Something exposed.
>
>  So I do
>
>  mb.calldefs(lambda d: d.name.startswith('Do')).exclude()
>
>  to hide the DoSomethings(). The problem is, class A has other methods
>  that I need, so I use A.include() to include it.

So you can change the order of exclude's

>  I get compile errors, saying "cannot instantiate abstract class." I
>  think what is happening, is that by excluding the pure virtual
>  functions in A, I'm fooling Py++ into generating invalid wrappers for
>  A (since all the pure virtual functions are "hidden").  Does "exclude"
>  work this way?

I always thought that Py++ generates code that compiles even if "pure
virtual" functions are excluded. I just added new test and saw that
this is not the case.

I will fix the problem in next few days.

Thanks for bug reporting.

> If not, Py++ must be getting confused about some other
>  aspect of the classes and I'll have to investigate further.

>  (Ideally what I really want is to finalize ALL classes unless I say so
>  explicitly that a method should be overridden.  This seems ideal for
>  performance.  I found the finalize function in the contrib folder, and
>  it seems to work, but I'm still not sure how to handle the more
>  complex case outlined above.)

As I said: I will fix the bug.

>  I also have another, entirely unrelated question :-D

And you will get entirely unrelated answer :-)

>  In the class hierachy I'm attempting to get something working with,
>  there is an entire category of classes (all with one common base
>  class) that are "owned" entirely by C++, since they have operating
>  system window resources. When you create a button, for instance, you
>  attach it to a window, and the window is responsible for destroying
>  it.  You call something like window->Destroy(), and then the Python
>  reference to the button has to become "invalid."
>
>  The other wrapper for this GUI library that exists (created with SWIG)
>  has a clever solution where the __class__ of the object is assigned to
>  a special "DeadObject" class, and any further attribute accesses on
>  the object raise Exceptions (instead of crash the program ;) ). I'm
>  having trouble figuring out to achieve this kind of behavior with
>  boost.  Basically, the object lifetime of a wxButton, for instance, is
>  not at all determined by any python objects which may reference it.
>  It's constructor takes a wxWindow* parent which immediately gains
>  ownership of the wxButton, and Destroys its children when it is
>  Destroyed. If the Python reference to the button goes away, nothing at
>  all should happen.  How does that idea fit into Boost's object
>  lifetime management, if at all?

I need to think a little about this. It could be nice if you can
create small test case, so I could play with it.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/