Boost logo

Boost :

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


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

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

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.


--- 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
> solution at, 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
> is non-const" on this page:
> 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++
> > 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
> > 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
> > 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
> > 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
> > from C++, there is no associated Python object.
> >
> > I want to provide Python access to the existing C++ instance of
> > and I don't know how. I'm going to start looking around in the
> > 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
> >
> > Thanks,
> > Tom.
> >
> >
> > To unsubscribe, send email to: <mailto:boost-unsubscribe_at_y...>
> >
> >
> > Your use of Yahoo! Groups is subject to
> >
> >

Boost list run by bdawes at, gregod at, cpdaniel at, john at