[C++-sig] how to handle bare references with ashared_ptrHeldType

Gregory Price price at ELLINGTON.com
Tue Sep 27 00:56:46 CEST 2005


David Abrahams wrote:
> > Here I use return_internal_reference on make_A;
> > so I should get a Python object "a" holding the C++ A
> > as a raw pointer.  But there's no trouble passing "a"
> > to get_x, which wants a shared_ptr<A>.
> > What is Boost.Python doing that makes this work?
> 
> It creates a shared_ptr whose custom deleter decrements the 
> refcount on the Python object owning the A.

Ah, very slick.  And when I try the same code
using the custom shared pointers I've actually got,
it tells me::

  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  Boost.Python.ArgumentError: Python argument types in
      test.get_x(A)
  did not match C++ signature:
      get_x(Common::SmartPtr<A>)

since, naturally enough, it doesn't know how to
do something so smart with these custom pointers.


I think I understand now what's going on.
So as Hans said, the answer is to use return_internal_reference.
Thanks to both of you!

I'd understood the opposite behavior from the documentation,
namely that Boost.Python would create a new shared_ptr
(or HeldType generally) from a returned A&.
Most pertinent is the passage (in the class.hpp docs)

  Because Boost.Python will always allow wrapped 
  instances of T to be passed in place of HeldType 
  arguments, specifying a smart pointer for HeldType
  allows users to pass Python T instances where a 
  smart pointer-to-T is expected.

which I now see is making exactly the point you say, David,
but which I'd read as saying that Boost.Python would
convert instances of T to instances of HeldType. (In hindsight
I see there's no way it could have known how to do that,
not for the custom shared-pointers I've been using.)

I think this reading was encouraged by the suggestion in
the paragraph just above it that this is exactly
what's done when HeldType is derived from T.

Here's another version of that passage:

  HeldType may be a smart pointer to T.  In this case
  Boost.Python will allow Python T instances to hold
  either a C++ T instance or a C++ HeldType instance.
  If HeldType is shared_ptr<T>, a from_python converter
  will be registered to accept a Python T instance holding 
  a C++ T instance and return a shared_ptr<T> instance
  with a custom deleter that decrements the Python refcount.

Is this right?

In particular, have I correctly gathered the following
about how Boost.Python works (and about its terminology):

 When a Boost.Python function is called (in Python),
 it finds a from_python converter to convert each
 of the arguments to a C++ object of the required type.
 Similarly, after invoking the underlying C++ function,
 a to_python converter is found to convert its return value
 into a Python object.

Where in the documentation is this sort of orientation 
material found?  (Or where should it be?)

Thanks for all your help.

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. 
==============================================================================================




More information about the Cplusplus-sig mailing list