[C++-sig] How do I make correct wrappers to interfaces while using shared_ptrs?
adam.preble at gmail.com
Mon Feb 6 01:49:49 CET 2012
On Feb 5, 2012 10:15 AM, "Jim Bosch" <talljimbo at gmail.com> wrote:
> On 02/05/2012 12:56 AM, Adam Preble wrote:
>> On Sat, Feb 4, 2012 at 8:48 PM, Jim Bosch <talljimbo at gmail.com
>> <mailto:talljimbo at gmail.com>> wrote:
>> Oh, you're right. I was confusing the manual way of doing
>> Python-side polymorphism (derived-class holders) with the more
>> automatic (and better) way you're doing it (with wrapper). Your
>> original code was fine in that regard.
>> Anyhow, looking closer, here's what you need to do:
>> - Put your code back to what it was before I told you to change it.
>> - Add another line, after the class wrappers:
>> register_ptr_to_python< boost::shared_ptr<__Communicatable> >();
>> That explicitly registers a shared_ptr converter for Communicatable.
>> I'm not sure why Boost.Python doesn't automatically do that when you
>> register converters for its derived classes (those are registered by
>> putting the shared_pr types in the template parameters to class_).
>> It might just be an oversight, or it might be that doing the base
>> class registration automatically would cause problems in some
>> The appears to do the trick. I'm wondering--how do you figure out stuff
>> like that? That isn't the kind of thing that could have just occurred
>> to me.
> To be honest, it's probably just a result of having stared at the
Boost.Python internals a lot while writing extensions for it. Ideally,
that's not something every user would have to do - it's a great library,
but the tutorial documentation does not go very deep, and the reference
docs are only good if you know what you're looking for. So just keep
mailing the list :)
> Another great way to learn more advance Boost.Python usage is to run
Py++. Even if you don't use it to produce your final wrappers (I generally
don't), looking at the output can teach you a lot of new tricks.
I will have to look at it in the next few days, although I fear it may be
an adventure on my real project.
> The important bit of knowledge in this case is that putting a shared_ptr
type in the template args to class_ does more than just register a
to-python converter for shared_ptrs. It also causes new instances created
in Python to be held in a shared_ptr. That's necessary in your case
because you're using enable_shared_from_this, but usually it isn't if you
just want to be able to return things by shared_ptr. So I usually use
register_ptr_to_python on all my classes instead, and that's why I was
already familiar with it.
Would using register_ptr_to_python explicitly and consistently instead of
the online shared_ptr declaration potentially eliminate some side-effects?
I cannot yet isolate why my real app crashes in python when it tries to do
an eval into one of my wrappers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cplusplus-sig