[C++-sig] [Py++] shared_ptr registration

[Roman Yakovenko]

On Wed, May 18, 2011 at 5:06 PM, Kirill Lapshin <kir at lapshin.net> wrote:
> On 18/05/2011 04:27, Roman Yakovenko wrote:
>>
>> Many years ago, I submitted a patch to this mailing list which adds
>> support for boost::shared_ptr< const T > to Boost.Python. It looks like
>> it was not applied.
>
> Good news that with added registration for shared_ptr<const foo2> it compiles fine with Boost 1.46.1 and works as expected. So I suppose your patch did get applied.

Cool. It looks like I have to fix Py++.

>>    Why foo2 doesn't have bp::register_to_python?
>> Mainly because Boost.Python doesn't support it and/or Py++ doesn't
>> recognize it.
>
> So now that Boost.Python supports it, any chance to get Py++ to automagically recognize it too?

Yes of course. I'll fix this bug, but it will not happen this or next week so.

>>    During code generation I get W1040 warnings saying that
>>    "shared_ptr<fooX> The declaration is unexposed, but there are other
>>    declartions which refer to it". I get them for both foo1 and foo2,
>>    even though Py++ did expose shared_ptr<foo1>. Why the warning is
>>    generated for foo1?
>>
>>
>> A small mistake in design and/or implementation. Please open a bug on
>> sourceforge with example and I will try to fix it.
>
> Ok, that is done now. I also went ahead and opened a bug (or rather a wishlist) for shared_ptr<const foo> support as well. Hope you don't mind.

The opposite - it is very good. If Py++ will report a lot of
irrelevant warning, the user will skip them, and the goal will not be
achieved.

I will try to fix it too.

> In the meantime I've got few more questions for you, if you don't mind.

I don't :-)

> Suppose I have two classes with exactly the same name in different namespaces, e.g. ns1::foo and ns2::foo. I include and rename them to say foo1 and foo2. However wrappers generated by Py++ are called foo_wrapper. Py++ even generates helpful warning saying that wrappers have the same name and it might cause problems. Indeed it does. This is not a huge problem, as I can work around it by modifying wrapper_alias property on both declarations. It would be nice though to handle it automatically -- for instance changing wrapper_alias upon rename, or just generating unique wrapper aliases based on fully qualified original name.

I understand why you are asking for this, but somehow I feel that this
functionality doesn't belong to Py++. The functionality could be
easily implemented by the user. You can use "partial_decl_string" or
"decl_string" properties for this purpose.
"partial_decl_string" - returns fully resolved name (
'::ns1::ns2::klass ), without default template arguments (for known
classes of course, mainly from std)

> Another problem I have, although didn't have a chance to try and reproduce it in simple standalone example, is one declaration generates following warning:
>
> WARNING: std::string const & base::name() const [member function]
> > warning W1049: This method could not be overriden in Python - method returns reference to local variable!
>
> After some searching through mail list archives I found your message from awhile back implying, if I understood it correctly, that this warning should only happen what non const reference is returned. Any comments on whether I tripped on a bug or whether it is expected warning? If latter is the case how to make it go away (short of adding to list of warnings to ignore). I can try to prep a simple repro if you wish.

This warning is reported for virtual functions (please confirm).
Consider, virtual or pure virtual function "wrapper" implementation
(the one you define in a class, which derives from
boost::python::wrapper), for a class implemented in Python.
Boost.Python don't have a place to store "std::string". You call the
function, get the result, which lives on stack and then you return it.
Once you exit the function, your std::string class instance is
destroyed.

I suggest you to try a simple example and analyze it.

> The last question I have (at least for now :) ) is:

It's okey

> Suppose I have a class with a pure virtual method which I don't want to expose for whatever reason, so I exclude this method, right? Now generated code fails to compile because it fails to instantiate an abstract wrapper. Any ideas how to solve/work around this?

I would like to see the example and to know what compiler do you use.

Even, in case Py++ doesn't have this functionality, you can change the
function alias to "__DoNotCallThisFunctionXYZ" and use
"override_precall_code" and "default_precall_code" functionality (see
docs and/or tests) to add a code, which will throw exception.
Could this help to solve your problem?

> Thank you so much for your support.


You are welcome.