Boost logo

Boost :

From: Vladimir Pozdyayev (ardatur_at_[hidden])
Date: 2005-08-29 01:23:37


Greetings.

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

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.

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?

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.

Comments?

-- 
TIA,
 Vladimir                          mailto:ardatur_at_[hidden]

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk