On 10/03/15 11:24 PM, Ernie Lee wrote:
> Hi Stefan,
>
> I updated my code so it now use 'boost::shared_ptr' class while
> specifying the held-type and i got exactly the same errors (i guess
> boost did recognize class even in different namespace).
>
> Any other theories of what could be wrong?
Hi Stefan,
I updated my code so it now use 'boost::shared_ptr' class while
specifying the held-type and i got exactly the same errors (i guess boost
did recognize class even in different namespace).
Any other theories of what could be wrong? Could it be that Python in
some cases tries to mana
Thank you for looking this up Stefan! It turned out that we actually
using boost::shared_ptr but in rather non-straight-forward way: it got pull
in to our own namespace so in the end Boost::Python::class_ is 'called'
with held-type set to a formally different type name. I will see if setting
held
Ernie,
it appears what you are seeing is the fact that boost.python only
supports boost::shared_ptr, but not std::shared_ptr. (See
https://svn.boost.org/trac/boost/ticket/6545). Is it possible for you to
switch to Boost's shared_ptr, at least for the Python bindings ? Yes, we
need to fix this urge
Hello,
I am working on adding Python binding to C++ project and run into the
following problem: For some reason Python tries to delete objects that are
still held by smart pointer instances in our C++ code.
We are using std::shared_ptr for memory management and classes exposed
through Boost::
