[C++-sig] Re: Less than transparent proxies

David Abrahams dave at boost-consulting.com
Tue Apr 15 21:33:19 CEST 2003


"Raoul Gough" <RaoulGough at yahoo.co.uk> writes:


> "Dave Abrahams" <dave at boost-consulting.com> wrote in message
> news:000801c30363$31948b10$9101a8c0 at penguin...

>>
>> Normally proxies in Python don't give you a way to distinguish the
> proxy
>> from the target class.
>
> So the C++ style of proxies doesn't fit Python. 

I'm not sure I'd say that.  All I meant is that the proxy generally
forwards everything to its delegate.

> I guess I was trying
> to transfer the concepts directly, but there's no actual need for
> this.

Maybe not.

>>
>> > Unfortunately, I seem to have hit a serious problem right away.
>> > The test code (below) produces "already has a registered
>> > to_python_converter" at load time, when defining the shared_ptr
>> > class which is already registered as a holder for the referant. I
>> > guess this was inevitable. Any suggestions or interest in the
>> > idea?
>>
>> It's interesting, but I don't think you've got the best approach
>> here.  Why the cumbersome extra syntax? Why the redundant
>> exception-handling code in your module initialization function?
>
> Don't really remember why the exception handler is there - unless it
> was necessary with the earlier version of the library

It was.

>> And why not just:
>>
>>
>> ----8<---- code starts ----8<----
>>
>> #include <iostream>
>> #include <ostream>
>> #include <boost/python.hpp>
>> #include <boost/shared_ptr.hpp>
>>
>> struct Hello {
>>   Hello () {
>>     std::cout << "Hello::Hello\n";
>>   }
>>
>>   ~Hello () {
>>     std::cout << "Hello::~Hello\n";
>>   }
>>
>>   void hello () { std::cout << "hello\n"; }
>> };
>>
>> BOOST_PYTHON_MODULE (proxy)
>> {
>>   using namespace boost::python;
>>
>>       class_<Hello, boost::shared_ptr<Hello> >("Hello")
>>         .def ("hello", &Hello::hello)
>>         .def ("_unique", &boost::shared_ptr<Hello>::unique)
>>         ;
>> }
>
> I'm surprised to learn that this works at all, so it's no wonder I
> didn't think of doing it that way :-) I would have thought that the
> Python object (e.g. "<proxy.Hello object at 0x00765730>") would not be
> suitable for the call to shared_ptr::unique(). On the C++ side, an
> object is _either_ a Hello or a shared_ptr<Hello>, and neither one of
> them provides both functions (hello and unique). So does the Python
> object get converted to the shared_ptr, rather than its target object,
> depending on the type of the C++ function being applied?

Precisely.  Basically, when you try to call a wrapped C++ function,
Boost.Python tries to convert each of the Python arguments to the
corresponding C++ argument type.  Since any Hello object held by
shared_ptr can be converted to a shared_ptr<Hello>&, that should work
just fine.

> Anyway, it looks like a nice and easy solution - thanks very much!

No sweat.

-Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com





More information about the Cplusplus-sig mailing list