Re: [boost] Boost.Python and slightly more tricky inheritance

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-29 07:18:18

Vladimir Pozdyayev <ardatur_at_[hidden]> writes:

> Greetings.

Hi!

The C++-sig is usually a better place for Boost.Python-related posts
(http://www.boost.org/more/mailing_lists.htm#cplussig).

> 1. First, about a bug (Boost 1.33.0, MSVC 7.1):
>
> After exporting
>   void test1( const char * ) {  }
>   void test2( std::string ) {  }
> we get an assertion failure _BLOCK_TYPE_IS_VALID( ... ) on
> std::strings longer than a dozen of characters:
>   test1( 'hello' ) # OK
>   test2( 'hello' ) # OK
>   test1( 'how do you do, tell me please' ) # OK
>   test2( 'how do you do, tell me please' ) # failure

And you think this is a bug in Boost code?  Can you post a
reproducible test case?  

I bet you didn't use Boost.Build to create your extension module, as
recommended in the Boost.Python documentation.  You probably are
linking with multiple copies of the runtime.

> 2a. From `Exposing Classes' tutorial section:
>
> "If Base is polymorphic, Derived objects which have been passed to
> Python via a pointer or reference to Base can be passed where a
> pointer or reference to Derived is expected."
>
> Now, that's a great feature, but I couldn't help noticing that what
> Boost.Python actually does, is even more useful: not only such
> pointers can be passed instead of Derived ones, but their Python
> counterparts _are_ fully qualified Derived representations, with all
> the methods and everything.  Probably worth mentioning in dox that
> way.

I think I would say something slightly different, but it's a good
point.  Joel?

In fact, it will work as long as the actual dynamic type of the object
has been exposed to Python.  However, if the type is something derived
from Derived, Boost.Python may not be able to determine the
most-derived type that's been exposed.

> 2b. Now, suppose we have one more derived class:
>
>   class Base { ... };
>   class Derived: public Base { ... };
>   class HiddenImplementation: public Derived { ... };
>   
> with Derived being no more than an interface. Naturally, we don't want
> to export HiddenImplementation to Python, but still want to retain
> automatic conversions from Base* to Derived* whenever
> pointer to HiddenImplementation object is passed to Python.
>
> Any way to do this? Without hack-ins?

Not without a hack, no.  But the hack might be simple:

#include <boost/python/object/inheritance.hpp> // non-public implementation details

...

   boost::python::object::register_conversion<Derived,HiddenImplementation>();
   boost::python::object::register_conversion<HiddenImplementation,Derived>();

> I was able to trick the system by defining the fake empty
> implemetation class
>   class HiddenImplementation: public Derived {  };
> right before the BOOST_PYTHON_MODULE and exporting it out there, but
> this kind of `solution' really annoys me. And I don't understand why
> it works, either :) . Oh, and it's only a partial solution, too: we do
> not have to access the real implementation class, but we still have to
> export something.

I don't think there's any chance of a solution that doesn't require
access to the real implementation class.

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