Re: creating a BPL instance from an existing C++ object.

From: tom-list_at_[hidden]
Date: 2001-04-02 00:51:32

David,

Before I comment on your proposal I should explain where I'm coming 
from.

I don't think I am part of the primary target audience for 
Boost.Python, because I don't need to expose (or extend) C++ classes, 
rather I need to expose C++ objects that I have already created, and 
I don't mind modifying my C++ code.  As a result, my understanding of 
the problem is a bit different than that of your proposal.

I see two seperate issues:

1) Exposing C++ objects to python.
I don't need to expose objects directly - I'm happy exposing 
functions that return objects, but I do need the functionality that 
you describe in the section of the docs titled "If you can't (afford 
to) copy the referent, or the pointer is non-const".
I see in your discussion of "An Existing Bug" that Boost.Python is 
supposed to prevent this.  I'm glad it doesn't.

2) C++ Dependenacies not mirrored in Python.
The hazards of C++'s containment (and the resulting dependency of the 
contained object) is simply not an issue for me.  I was intending to 
bump up the reference count of the python object corresponding to my 
C++ object to reflect the fact that my C++ code would hold its own 
reference to the object.  This is because I don't want the object 
deleted for me, even when there are no Python references left.  
(Actually, I was intending that my C++ object would hold a pointer to 
the corresponding Python object so that I could delay updating my C++ 
object if any Python references to it existed, and so that I could 
delete the Python object in my C++ objects' dtor.)

Therefor, the danger you mention in the section about non-const 
pointers is not a concern for me, so that soln is fine.  As a result, 
if you proceed with your planned changes I would prefer that you 
allow for "unmanaged" in place of "owned_by_arg(n)" as you suggest in 
one of your postings.

A couple of unrelated comments regarding your proposal:

Regarding your dicussion of how to handle wrapped functions that 
return const references.  I would not expect this to be possible: you 
can't return a const value to Python, so there is no appropriate 
behavior for Boost.Python.  You should need to const_cast it first, 
then return a non-const value.  Of course, not allowing it might not 
be acceptable to people who must wrap existing code that they can't 
modify.

Regarding the proposal by Ullrich that would require partial template 
specialization.  I've read that even VC7 won't support this feature.

Regarding the use of EH to handle overload resolution.  I wasn't 
planning to use this feature, but if I were, its use of EH would 
scare me off.

Tom.

--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> This has come up several times. There is a limitation in 
Boost.Python which
> makes trying to do what you want dangerous at best. I posted a 
proposed
> solution at http://groups.yahoo.com/group/boost/message/10144, but 
given the
> deafening silence I got as a response, I just keep directing people 
at the
> section titled "If you can't (afford to) copy the referent, or the 
pointer
> is non-const" on this page:
> http://www.boost.org/libs/python/doc/pointers.html.
> 
> I would happily make the proposed change to Boost.Python, but would 
like to
> hear /something/ from users before undertaking any redesign.
> 
> -Dave
> 
> P.S. we don't say "BPL" anymore... we at boost are afraid of 
running out of
> acronyms ;-).
> 
> 
> ----- Original Message -----
> From: <tom-list_at_h...>
> To: <boost_at_y...>
> Sent: Saturday, March 31, 2001 5:20 PM
> Subject: [boost] creating a BPL instance from an existing C++ 
object.
> 
> 
> > I'm using VC6 SP4 on Win2K SP1, with Boost 1.21.1 & Python 2.0.
> >
> > I want to create a 'BPL extension instance' object from an 
existing
> > C++ object.
> >
> > Let me start with a conventional use of the BPL that leads to my
> > problem...
> >
> > My extension module creates a BPL extension class based on a C++
> > class (call it CB).
> >
> > The user instantiates it ...
> > >>> B = CB();
> >
> > Now BPL code instantiates the associated C++ class and ties it to 
the
> > new BPL extension instance object.  Correct?
> >
> > To get to my problem, let's say that the C++ class CB contains
> > another class CBa.  Then CBa will automatically get instantiated 
when
> > the BPL code instantiates CB.
> >
> > The CBa class, by the way, is wrapped, so there is an associated
> > Python (BPL extension instance) type, but since CBa got 
instantiated
> > from C++, there is no associated Python object.
> >
> > I want to provide Python access to the existing C++ instance of 
CBa,
> > and I don't know how.  I'm going to start looking around in the 
BPL
> > source code in the hopes of figuring out how to do this, but if
> > anyone knows offhand that it is or isn't possible, please let me 
know.
> >
> > Thanks,
> > Tom.
> >
> >
> > To unsubscribe, send email to: <mailto:boost-unsubscribe_at_y...>
> >
> >
> > Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/
> >
> >