<p><br>
On Feb 5, 2012 10:15 AM, "Jim Bosch" <<a href="mailto:talljimbo@gmail.com">talljimbo@gmail.com</a>> wrote:<br>
><br>
> On 02/05/2012 12:56 AM, Adam Preble wrote:<br>
>><br>
>><br>
>> On Sat, Feb 4, 2012 at 8:48 PM, Jim Bosch <<a href="mailto:talljimbo@gmail.com">talljimbo@gmail.com</a><br>
>> <mailto:<a href="mailto:talljimbo@gmail.com">talljimbo@gmail.com</a>>> wrote:<br>
>><br>
>> Oh, you're right. I was confusing the manual way of doing<br>
>> Python-side polymorphism (derived-class holders) with the more<br>
>> automatic (and better) way you're doing it (with wrapper). Your<br>
>> original code was fine in that regard.<br>
>><br>
>> Anyhow, looking closer, here's what you need to do:<br>
>><br>
>> - Put your code back to what it was before I told you to change it.<br>
>><br>
>> - Add another line, after the class wrappers:<br>
>><br>
>> register_ptr_to_python< boost::shared_ptr<__Communicatable> >();<br>
>><br>
>><br>
>> That explicitly registers a shared_ptr converter for Communicatable.<br>
>> I'm not sure why Boost.Python doesn't automatically do that when you<br>
>> register converters for its derived classes (those are registered by<br>
>> putting the shared_pr types in the template parameters to class_).<br>
>> It might just be an oversight, or it might be that doing the base<br>
>> class registration automatically would cause problems in some contexts.<br>
>><br>
>><br>
>> The appears to do the trick. I'm wondering--how do you figure out stuff<br>
>> like that? That isn't the kind of thing that could have just occurred<br>
>> to me.<br>
>><br>
><br>
> 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 :)<br>
><br>
> 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.<br>
></p>
<p>I will have to look at it in the next few days, although I fear it may be an adventure on my real project.<br></p>
<p>> 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.</p>
<p>Jim,</p>
<p>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.<br>
</p>