Re: [C++-sig] how to handle bare references with a shared_ptr HeldType
Hans Meine wrote:
Hmm. What about return_internal_reference (which I am using a lot)? AFAICS, the C++ A object will not be deleted as long as B is not deleted, because of the shared ptr. OTOH, during the lifetime of the A python wrapper, B will not get deleted because of the custodian-ward relationship initialized via return_internal_reference. Does that make sense?
I agree with the second half of that -- return_internal_reference will keep the B instance alive as long as the wrapped A instance exists. But now say the wrapped A instance dies; the HeldType=shared_ptr<A> instance will think it's the only shared_ptr for that A instance, and will delete it. Now the shared_ptr<A> inside the B instance is dangling. I've lost as soon as I let Boost.Python create a new shared_ptr<A> from the bare A& -- the only way to avoid a dangling pointer then is to ensure that the A instance never dies at all. Is there a way to tell Boost.Python not to make a shared_ptr for this return value -- to override the HeldType just for this function's return value? Alternatively, to tell Boost.Python always to leave bare A references as they are? Or perhaps there's a simpler solution that I'm missing. Thanks, Greg ============================================================================================= Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ==============================================================================================
On Thursday 22 September 2005 16:37, Gregory Price wrote:
Is there a way to tell Boost.Python not to make a shared_ptr for this return value -- to override the HeldType just for this function's return value? Alternatively, to tell Boost.Python always to leave bare A references as they are?
Or perhaps there's a simpler solution that I'm missing.
Ah. I knew I was overlooking something. Is changing the HeldType an option for you? OTOH, if you use return_internal_reference, BP should know that creating a shared_ptr with a refcount of 1 is evil.. is that really what it does? -- Ciao, / / /--/ / / ANS
Hans Meine <meine@kogs1.informatik.uni-hamburg.de> writes:
On Thursday 22 September 2005 16:37, Gregory Price wrote:
Is there a way to tell Boost.Python not to make a shared_ptr for this return value -- to override the HeldType just for this function's return value? Alternatively, to tell Boost.Python always to leave bare A references as they are?
Or perhaps there's a simpler solution that I'm missing.
Ah. I knew I was overlooking something. Is changing the HeldType an option for you?
OTOH, if you use return_internal_reference, BP should know that creating a shared_ptr with a refcount of 1 is evil.. is that really what it does?
No, that's not what it does. When you use return_internal_reference it creates a Python object holding the C++ object with a raw pointer. Isn't that in the documentation? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Saturday 24 September 2005 00:38, David Abrahams wrote:
Hans Meine <meine@kogs1.informatik.uni-hamburg.de> writes:
OTOH, if you use return_internal_reference, BP should know that creating a shared_ptr with a refcount of 1 is evil.. is that really what it does?
No, that's not what it does. When you use return_internal_reference it creates a Python object holding the C++ object with a raw pointer. Isn't that in the documentation?
That's how I understood it in the past, but I am not experienced with customized HeldTypes, and Gregory seemed to be concerned that it does so:
On Thursday 22 September 2005 16:37, Gregory Price wrote:
Is there a way to tell Boost.Python not to make a shared_ptr for this return value -- to override the HeldType just for this function's return value?
So the answer really is: Use return_internal_reference. Concerning the documentation question: The class_ documentation reads "Heldtype [...] Specifies the type which is actually embedded in a Python object wrapping a T instance. More details below." So I would've assumed that every T wrapper actually contains a smart_ptr if that's the HeldType. One could then make more clear that it's not always the case. The return_internal_reference docs say "Note that if the target Python object type doesn't support weak references, a Python TypeError exception will be raised when the function being wrapped is called." The longer I think about that sentence, it could actually indicate the use of weakrefs. ;-) Finally, I propose the attached (not-too-related) patch to the documentation, which basically reorders some HeldType explanations to make their overall relation more clear. Ciao, / / .o. /--/ ..o / / ANS ooo
Hans Meine <hans_meine@gmx.net> writes:
Finally, I propose the attached (not-too-related) patch to the documentation, which basically reorders some HeldType explanations to make their overall relation more clear.
I do appreciate your efforts, but I'm sorry to say that I don't see how that patch clarifies anything. If you can explain that, I might be inclined to apply it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Tuesday 01 November 2005 16:17, David Abrahams wrote:
I do appreciate your efforts, but I'm sorry to say that I don't see how that patch clarifies anything. If you can explain that, I might be inclined to apply it.
I guess that it does not make things clearer for you, since you know what it explains and you have no difficulties in following the explanations; for me it makes things clearer simply because all items begin with "if/when <condition>", so I get a faster impression of what cases there are and whether the whole table is of interest for me. Ciao, / / /--/ / / ANS
Hans Meine <meine@kogs1.informatik.uni-hamburg.de> writes:
On Tuesday 01 November 2005 16:17, David Abrahams wrote:
I do appreciate your efforts, but I'm sorry to say that I don't see how that patch clarifies anything. If you can explain that, I might be inclined to apply it.
I guess that it does not make things clearer for you, since you know what it explains and you have no difficulties in following the explanations; for me it makes things clearer simply because all items begin with "if/when <condition>", so I get a faster impression of what cases there are and whether the whole table is of interest for me.
Hmm. Can we get someone to agree with Hans? The problem is that of course Hans' version is clearer to him, just like mine is perfectly fine for me. For reference, his patch is attached to http://article.gmane.org/gmane.comp.python.c++/8631 -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hans Meine <hans_meine@gmx.net> writes:
On Saturday 24 September 2005 00:38, David Abrahams wrote:
Hans Meine <meine@kogs1.informatik.uni-hamburg.de> writes:
OTOH, if you use return_internal_reference, BP should know that creating a shared_ptr with a refcount of 1 is evil.. is that really what it does?
No, that's not what it does. When you use return_internal_reference it creates a Python object holding the C++ object with a raw pointer. Isn't that in the documentation?
That's how I understood it in the past, but I am not experienced with customized HeldTypes, and Gregory seemed to be concerned that it does so:
On Thursday 22 September 2005 16:37, Gregory Price wrote:
Is there a way to tell Boost.Python not to make a shared_ptr for this return value -- to override the HeldType just for this function's return value?
So the answer really is: Use return_internal_reference.
Concerning the documentation question: The class_ documentation reads "Heldtype [...] Specifies the type which is actually embedded in a Python object wrapping a T instance. More details below." So I would've assumed that every T wrapper actually contains a smart_ptr if that's the HeldType. One could then make more clear that it's not always the case.
Clarified, thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Gregory Price -
Hans Meine -
Hans Meine