--PGPMime-Boundary-D910DAAD
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

On 22 Oct 2003 at 8:10, David Abrahams wrote:

>  In any case, I'm done discussing our communication disconnect, and I'm
>  returning to technical issues for the remainder of this thread.

No problem, and thanks for indulging my off-topic interest in this 
matter. Someday I'll write a book on managing IT projects where I'll 
hopefully improve on "The Mythical Man Month".

>  None of this is to say that there's something wrong with the
>  "metadata" approach. My proposal isn't completely general - it doesn't
>  apply in cases where virtual function default implementations aren't
>  involved.  The metadata probably would be implemented with a virtual
>  function on Holder classes which would return true iff the lifetime of
>  the held C++ object was dependent on that of the Python object.

Interesting, and a source of ideas for my own solution.

>  Sadly, I don't know when I'd have time to implement any of this; I'm
>  desperately trying not to fall behind on a book I'm writing.

I'm thinking the best short-term stop-gap solution is an alternate 
call_method which basically disables the dangling pointer check. Then 
you can mark off functions in pyste which would fall foul of this 
particular problem on a case-by-case basis.

The:
       object self(handle<> (borrowed(m_self)));
       return extract<Foo*> (self.attr("f")());

... solution I previously mentioned is of course unsuitable because 
attr() cannot take parameters.

Cheers,
Niall





--PGPMime-Boundary-D910DAAD
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP5bHBMEcvDLFGKbPEQLvHQCffc39HAnVrDRrJ9MhEmFf2bGX9OcAoOkA
EELFCJsHXJZIsvPf4+ABFLwr
=2P2l
-----END PGP MESSAGE-----

--PGPMime-Boundary-D910DAAD--