added 'construct_custodian_for' and test#8
Conversation
(fixes problem that 'with_custodian_and_ward_postcall' doesn't work in connection with 'make_constructor')
|
Sorry to ask that here, but how do you actually test that the correct custodian-and-ward relationship is established or not ? In the example 4, it seems that the problem will appear, or not, depending on how long B3.a_content is referenced in python. Do you have advice on how prevent or debug such misbehavior ? EDIT: I just spotted the sys.getrefcount for the testing |
|
Bump ! |
|
I'm wondering if this might be the wrong repository. Where is the main boost::python development going on? |
|
According to this page, it seems to be the right place. However, boost.python development is not really active (sadly), perhaps contributors that do not wish to invest time anymore should leave so we can see who is actually committed to this project. |
|
Hi, this is definitely the right place for such discussions and patches. The explanation is very clear, and the code looks sensible, too. I'll try to find some time to test it, and (hopefully) eventually merge it. Thanks ! |
(note: I will update the documentation as well when this pull request gets accepted)
This pull request proposes a fix for the long-standing problem that
with_custodian_and_ward_postcalldoesn't work in connection withmake_constructor(see e.g. https://mail.python.org/pipermail/cplusplus-sig/2007-June/012145.html).Consider the following class definitions:
and the corresponding boost::python glue code
In this code
#1works as desired#2works, but is a bit counter-intuitive because indexing suddenly starts at 1#3causes an "argument index out of range" error#4runs, but fails to establish the desired custodian-and-ward relationship (i.e.B3.a_content()may crash because the containdAinstance can be deleted prematurely)The pull request introduces a new policy
construct_custodian_forwhich solves problems#2-4. It is used like this: