[C++-sig] to_python converter and make_getter

Giuseppe Corbelli giuseppe.corbelli at copanitalia.com
Wed Jan 23 09:16:57 CET 2013


On 23/01/2013 06:34, Michael Wild wrote:
>>> Dear all
>>>
>>> I have defined a to_python converter following
>>> http://misspent.wordpress.com/2009/09/27/how-to-write-boost-python-converters.
>>>
>>> Everything is fine and dandy, however what bugs me is having to specify
>>> a return_value_policy<return_by_value>() for every make_getter call.
>>> Looking through the sources it seems that I should be able to tell
>>> make_getter what the default policy should be by somehow specializing
>>> default_member_getter_policy and default_datum_getter_policy. However,
>>> is this the right way to go, or should I attack the problem at a lower
>>> level, e.g. by specializing default_getter_by_ref? Or should I directly
>>> specialize make_getter?
>>>
>>
>> Could you provide a little more information about what you're trying to
>> do and what the error is?  I'm surprised that you're having to specify a
>> call-policy manually for return-by-value; I've used by-value to_python
>> converters plenty of times without ever having to do that.
>>
>> Jim
>>
>
> I don't have to do it for functions that return by value, only for
> static members that I want to wrap in a static property.
>
> I put the example here: https://gist.github.com/4602341

Since you're wrapping static members why don't you create once and for all a 
something PyObject* that wraps up what you need?
I mean, something like

struct A
{
static std::string staticStdString;
static QString staticQString;
};

struct A_Wrap
{
A_Wrap() : staticStdString(A::staticStdString)
{}

bpy::object staticStdString;
}

First you register the converter(s).
Second you instantiate the one and only A_Wrap.
Everytime you access staticStdString just return A_Wrap::staticStdString.

-- 
             Giuseppe Corbelli
WASP Software Engineer, Copan Italia S.p.A
Phone: +390303666318  Fax: +390302659932
E-mail: giuseppe.corbelli at copanitalia.com


More information about the Cplusplus-sig mailing list