[C++-sig] [boost.python] convert swig-wrapped c++-return values to python with boost.python

[David Abrahams]

--
Dave Abrahams
Boostpro Computing
http://boostpro.com

On Jul 21, 2008, at 4:56 AM, Maximilian Matthe <Maxi.Matthe at web.de>  
wrote:

> David Abrahams schrieb:
>> on Sun Jul 20 2008, Maximilian Matthe <Maxi.Matthe-AT-web.de> wrote:
>>> David Abrahams schrieb:
>>>> on Sun Jul 20 2008, Maximilian Matthe <Maxi.Matthe-AT-web.de>  
>>>> wrote:
>>>>
>
>>>>> on Sun Jul 20 2008, Maximilian Matthe <Maxi.Matthe-AT-web.de>  
>>>>> wrote:
>>>>> I dont want to return wxWindow by value, but by reference/ 
>>>>> adress. Thus
>>>>> the bp::reference_existing_object call policy.
>> You can't use that policy unless you're returning a Boost.Python- 
>> wrapped
>> class.  Its whole purpose in life is to make an instance of the class
>> where the C++ object is held by raw pointer.  I suggest you leave  
>> it out.
>
> Uh, well, then this could be written into the documentation,  
> couldn't it?

Lots more could. Care to submit a patch?

> Then I wouldn't have searched so long for a solution.

Sorry

>
>> I can't imagine what purpose that const_cast could serve.  Surely
>> wxPyMake_wxObject doesn't modify its first argument?  I suggest you
>> leave it out.
>>
> No, the const_cast is needed. wxPyMake_wxObject wraps a PyObject  
> around the passed wxObject (any wxWidgets-Class). This object is  
> then passed to python (contains a pointer to the actual wx-object),  
> which can be modified in python, thus the const_cast is needed.

I can't see the code any more, but it sure looked to me like you were  
adding or removing const from/to the pointer type rather than the  
pointee.
>
>> HTH,
>
> I have found a solution after a very long search and with help from  
> the irc-channel: Roman Yakovenko has created the return_value_policy  
> return_pointee_value. Here's his announcement for that:
> http://mail.python.org/pipermail/c++-sig/2006-November/011568.html
> Maybe it would be good to have that in boost-python? He has already  
> added it to his Py++ code generator.

A patch with docs and tests would go as long way toward making that  
happen.

>
> So my problem seems to be solved in this case...
> Thanks for your help!

NO

> PS: I'm currently reading your MPL-Book and like it very much,  
> although it's quite complicated to see through all the details after  
> reading one chapter once :-)


Glad you're enjoying!