Date: 2001-06-27 00:17:07
> 1. I cannot do cross module inheritance (i.e., have a base class
> defined in one module, and then try to wrap a derived class in
> module where I need to be able to reflect this inheritance to python
> with "declare_base"). The code and its interface are far too large
> to make it feasible to wrap in a single module. I've looked at the
> boost mailing list and I found a few messages related to this
> from April, but there didn't really seem to be a final answer.
Yes, after some preliminary testing I stopped working on the
cross-module support for declare_base. The reason is that we do not
need this in our project. However, I would be interested to help if
someone else picks this up, and I would be happy to share my
modifications to provide a starting point. With the modifications, it
works (to a point) with Linux gcc and Tru64 cxx. However, it does not
work with VC60SP4, mingw32 and the Silicon Graphics compiler. This
probably has to do with differences in the dynamic loaders. I am
guessing that some Boost.Python internal table has to be exported from
one module and imported in the other module. (The thing to look at is
> 2. I make fairly heavy use of abstract base classes (with pure
> functions), and have other objects which expect to be able to take
> instances of these abstract classes as arguments to methods. I can
> the abstract types and use them in a given module with no problem,
> cannot seem to export the abstract types for use in other modules.
> example, if I have a class "AbstractBase" that has pure virtual
> the following export statement always fails:
This is something that I have not tried, and not thought about.
this is something that we do not currently need in our project.
I am sorry if this is not very helpful. Mike, from your area code I
infer that we are geographically very close (I am in Berkeley). It
would be easy to meet and talk about Boost.Python development. Maybe
together (and with David's advice) we can work out solutions for your
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk