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@ugnn.ru