[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