Re: [C++-sig] Custodian & ward
Hi, Niall asked:
... and each FXWindow instance maintains a list of its children, and deletes its children when it gets deleted, then how do I apply custodian & ward to ensure that when the parent instance is deleted, python knows not to delete the children?
I've experienced the same problems when writing wrappers for LLVM. My conclusion is that BPL doesn't obey with_custodian_and_ward and/or return_value_policy in case of constructors. This is what I think should work, but eventually this crashes in a double delete: struct P; struct C { explicit C(P& parent); // transfers ownership of this to parent }; BOOST_PYTHON_MODULE(init_policy) { class_<C, boost::noncopyable> ("C", init<P&>() [with_custodian_and_ward<2, 1, return_value_policy<reference_existing_object> >()]); } I've attached a compiling example of the crash, and how to work around by using a factory function. BR, Jarno -- Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++
"Jarno Seppänen" <js.nospam@wolke7.net> writes:
Hi,
Niall asked:
... and each FXWindow instance maintains a list of its children, and deletes its children when it gets deleted, then how do I apply custodian & ward to ensure that when the parent instance is deleted, python knows not to delete the children?
I've experienced the same problems when writing wrappers for LLVM. My conclusion is that BPL doesn't obey with_custodian_and_ward and/or return_value_policy in case of constructors.
What effect do you expect the return_value_policy to have? The ctor is returning a brand new object every time. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi, David writes:
"Jarno Seppänen" <js.nospam@wolke7.net> writes:
Niall asked:
... and each FXWindow instance maintains a list of its children, and deletes its children when it gets deleted, then how do I apply custodian & ward to ensure that when the parent instance is deleted, python knows not to delete the children?
I've experienced the same problems when writing wrappers for LLVM. My conclusion is that BPL doesn't obey with_custodian_and_ward and/or return_value_policy in case of constructors.
What effect do you expect the return_value_policy to have? The ctor is returning a brand new object every time.
My purpose in using return_value_policy<reference_existing_object> for the constructor is to make BPL not delete the newly constructed object, because that will cause a double delete. The LLVM library (and Niall's FXWindow library IIUC) semantics are that the child object constructor transfers the ownership of itself to the parent, and the child object must _not_ be deleted, because the parent owns it. At the same time the semantics guarantee that the child object is not deleted before the parent is, i.e., use for with_custodian_and_ward, no? Cheers, Jarno -- Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis ++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++
On 11 Jun 2005 at 8:47, Jarno Seppänen wrote:
The LLVM library (and Niall's FXWindow library IIUC) semantics are that the child object constructor transfers the ownership of itself to the parent, and the child object must _not_ be deleted, because the parent owns it. At the same time the semantics guarantee that the child object is not deleted before the parent is, i.e., use for with_custodian_and_ward, no?
I did get custodian & ward to prevent *python* deleting either the parent before the child or the child before the parent, but that's not what I want to do. I *fully* want python to be able to delete either at any time with immediate effect so it became clear that custodian & ward is of no use to me. What I do have a problem with is the C++ library deleting stuff without telling python. There isn't much I can do to stop that, but I can tell python somehow to permanently forget about those instances. Cheers, Niall
participants (3)
-
"Jarno Seppänen" -
David Abrahams -
Niall Douglas