Shouldn't you be wrapping a managed pointer to your C++ instance? That stages the destruction properly by keeping the virtual function table around long enough to call a virtualised destructor.
Search the archives of this mailing list. There are lots of examples. Niall On 24 Nov 2011 at 0:07, Adam Preble wrote: > I'm using boost 1.47 on Windows Vista, with Visual Studio 2010. > > My situation is something like this: > > 1. I have a base interface in C++ to which I've exposed a wrapper in Python. > 2. In the C++ source, I have a class that contains multiple instantiations > of said interface. We can call it Foo. Foo has been wrapped too. > 3. In Python, I've implemented this interface. > 4. I have an instance of the object floating around that I created in > Python, contained within a Foo instantiate in Python. > 5. The code goes out of scope, and Foo's destructor starts. Foo's > destructor will try to delete its implementations of the interface. > 6. Upon running into the Python implementation of the interface, we crash. > > Actually, with gcc in Linux I don't see anything bad happen at all. It > isn't until I try this on Windows that all hell breaks loose. What I've > found with my code is that this isn't Visual Studio 2010's fault. It's > calling me out on something stupid that gcc/Linux let slide. I think the > fundamental question is: how I can get the resource freed through Python > correctly? > > If I let the Python class implementation go out of scope on its own, I > don't see any problems. Furthermore, Foo is content on its own. It's the > merging of the two that brings me problems. Particularly, the program > crashes when I try to delete the Python-instantiated object. I'm not > entirely surprised by this, but I have no real good way to try to tackle > this problem. I don't even have good, crisp source code to show the > problem yet. The code where this has happened has been running fine on > Linux for awhile so I don't have an isolated case to post. I can work > towards that if I've confused everybody. > > One last note. I did put some test print statements in the virtual > destructor I had written for the interface. I do see that code does run, > so I think it ultimately comes down to the memory freeing negotiated > between Python and my C++ runtime. > -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
