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

From: Vladimir Pozdyayev (ardatur_at_[hidden])
Date: 2005-08-30 01:35:40

Hello David,

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

Thought that, but had to stick to whatever mailing list I am already
subscribed, for this time :( .

>> 1. First, about a bug (Boost 1.33.0, MSVC 7.1):
>> ...<C++ code>...
>>   test1( 'hello' ) # OK
>>   test2( 'hello' ) # OK
>>   test1( 'how do you do, tell me please' ) # OK
>>   test2( 'how do you do, tell me please' ) # failure
DA> And you think this is a bug in Boost code?  Can you post a
DA> reproducible test case?  

Well, that was the test case, and I hope it's reproducible... okay,
here's the full source, if that's what you mean:

#include <boost/python.hpp>
#include <string>
void test1( const char * ) {  }
void test2( std::string ) {  }
BOOST_PYTHON_MODULE( getting_started1 ) {
        boost::python::def( "test1", test1 );
        boost::python::def( "test2", test2 );
}

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

I followed instructions in Building and Testing / Using the IDE for
your own projects section. Dox warn about compile and link errors
possibility when wrong project settings are used, but say nothing
about runtime failures, AFAICS.

Now that you've mentioned that, I went and stuffed the above code
right into \libs\python\example\getting_started1.cpp, then bjammed it.
Got the same assertion failure in Python session. Does this count?

DA> #include <boost/python/object/inheritance.hpp> // non-public implementation details
DA> ...
DA> boost::python::object::register_conversion<Derived,HiddenImplementation>();
DA> boost::python::object::register_conversion<HiddenImplementation,Derived>();

Thanks, I'll try this.

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

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

Er... The solution above is exactly the one which does not require
access to the real implementation class, because it exports the fake
class instead. I was just wondering whether it could possibly be
legal. And whether we could do without exporting any implementation
class at all.

-- 
Best regards,
 Vladimir                            mailto:pvv_at_[hidden]