[C++-sig] boost.python - C++ class overridden in python causes slicing
troy d. straszheim
troy at resophonic.com
Tue Sep 8 21:28:13 CEST 2009
Jean-Sébastien Guay wrote:
> Hello Troy,
>> I've been doing a bunch of work with osg recently. I like it and
>> badly miss some boost.python bindings. I'd be very interested to
>> have a look at the code here, maybe pitch in a bit. Is there a git
>> archive I can clone, and a failing test I can run?
> I was thinking of setting up a googlecode project for this work, because
> there is at least one other person who might be interested in working
> with me on it (Paul Melis). I'll see if I can do that soon.
> I prefer to work with svn though (used to be CVS was oldschool, now it's
> SVN, I know I'm behind the times), hope that's not a problem for you.
Doesn't really matter to me.
> I would have liked to get the basic functionality working before setting
> that up because there's already another project trying to wrap OSG to
> python (osgSwig), so I'd like to be able to prove that my solution is
> competitive with that one.
Competitive isn't an issue, as swig and boost.python bindings aren't
really compatible (or is that 'sip' bindings that aren't compatible?).
Personally I prefer a manual approach over automatically generated
bindings; apparently for the same reasons that some compiler writers
insist on handwritten recursive descent parsers. I know there are smart
people around that have worked long and hard on generators, I don't want
to start any fights. YMMV.
> For reference, osgSwig have been having trouble lately wrapping the
> classes derived (multiply) from osg::MixinVector<T>, and have relied on
> patches to OSG that remove that derivation (essentially going back to
> the OSG 2.6 versions of those classes). On the other hand, using
> boost.python I can wrap things as I want, and I don't have any problem
> wrapping classes derived from MixinVector<T>, so I think it's a better
> route in the long run.
Yes exactly. Being intrusive is just not an option, for one. More
examples are easy to come up with, e.g. wants fine-grained control over
the python interface to provide things like conversions to native python
types (datetime, numpy arrays), or to provide slicing notation and
iterators on a node's children, say
> Anyways, yeah, I'll set up that project so you can run the actual code
> and see the problem firsthand, hopefully that will make it easier to
> help out.
Looking forward to it.
More information about the Cplusplus-sig