[C++-sig] More inheritance problems

[Charly Bicker]

Dear Holger,

thank you for your reply!

> Why is that needed?
> >>> t = testInheritance.Third(testInheritance.Derived())
> her in reality an instance of DerivedWrapper is created, and then
> passed to C++. When you then do `t.get_base()` and instance of
> DerivedWrapper will be returned (there is actually some "magic" going
> on that boost python can associate your `boost::shared_ptr<Base>`
> with
> the PyObject that is a DerivedWrapper). Because that object is a
> `DerivedWrapper` the `.name` calls DerivedWrapper::name.
> 
> In your second example the object is create with the call `_base =
> boost::shared_ptr<Base>(new Derived());`. This class is no subclass
> of
> `DerivedWrapper` nor `BaseWrapper`, so you can not call a member
> function of the wrappers. That is why you get the error.

I see. I was working under the assumption, that the boost python magic included the treatment of classes Derived as their DerivedWrapper.

Unfortunately, this leads me to another problem. In my simple example, the problem is fixed by just adding another function definition. However, for various reasons, some of my wrappers do more than just handle the function overloading: they convert certain objects to and from python. The conversions in question cannot be done with the usual converter classes, due to the use of an external C++ library with python bindings which is somewhat special (and might warrant another mail at some point). Now, wrapping like this with the behavior you describe will of course have disadvantageous effects because the conversions will only be done if the object was instantiated from python. Is there a way around this? Can I convince boost python to treat (i.e. convert) all instances of Derived as DerivedWrapper? If the answer is no, then that would obviously mean that the wrappers must not contain more than code for overloading and I would have solve the problems with the converters some other way.

Best regards,
Karl