[C++-sig] The "return always existing pointer throws dangling error" problem

[Niall Douglas]

Just run into this one myself whereby when querying a FXObject 
subclass for its metadata (a FXMetaClass) it throws "attempt to 
return dangling pointer". I've read Dave's comments at 
http://mail.python.org/pipermail/c++-sig/2003-August/005288.html & 
http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/1781761 and I 
was wondering, surely it is fairly trivial for BPL to know when a 
python object holding a reference to a C++ thing is holding it in a 
non-ownership way?

Let me clarify: From what I understand, most return policies destroy 
their associated C++ object instance when its python representation 
expires. Mostly that's a copy of the C++ object instance and when 
this is the case, the throwing of the error is correct.

However, if the object instance was allocated by new (and thus its 
policy was manage_new_object), then doesn't that strongly imply that 
the receiving object takes ownership of a newed pointer as well 
because the return policy setting is an artifact of how the C++ code 
works? Therefore in this situation auto_ptr style transference would 
be more useful.

return_internal_reference is also different - if you attach lifetime 
to self which most do, then when a virtual override in python returns 
an internal reference to either C++ or python code invoking that 
function, surely BPL is attaching the lifetime of the internal 
reference to the "self" instance and not to the temporary object 
created during call_method? Therefore surely the error is reporting 
the wrong thing dangling?

Lastly looking through the docs I encountered a thing called ptr<> 
which while it appears to help me in C++, if I were to subclass 
FXObject with my own class in python (whereupon I must provide my own 
custom FXMetaClass to describe it) I'd be smack bang right back into 
problem-land.

Thoughts? I appreciate that this has been addressed before, and that 
Dave who is uber-intelligent has said he's not sure about the correct 
solution. But I can't see how BPL doesn't know where one of its own 
pointer containers got its pointer from?

If I'm missing something tragically obvious, perhaps some sort of 
ownership policy might be needed?

Lastly, while the posts I referred to promise workarounds, I can't 
see any which don't involve altering the original C++. Can I 
explicitly disable the dangling pointer check? Though, ideally, I'd 
still want to always tie any returned FXMetaClass always to its 
associated FXObject.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031021/aacf5bbf/attachment.pgp>