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

[Kirill Lapshin]

On 18/05/2011 04:27, Roman Yakovenko wrote:
> Not in a few next months. The SVN contains tested and documented
> version. It is perfectly save to use it.

Fair enough. Just asking.

> Basically Py++ inspects every exported declaration and looks for smart
> pointers and stl containers. Take a look on
> creators_factory.types_database_t class and follow it within bpcreator.py
> Once, it has all the information about the exported types and their
> dependencies, it starts to "expose". So, you really should not / not
> supposed to configure something.

Perfect.

>     Is there any way to force Py++ to add such registration?
>
>
> Yes:
>
> mb = module_builder_t( ... )
> foo2 = mb.class_('foo2').add_registration_code(
> 'bp::register_ptr_to_python< boost::shared_ptr< const foo2 > >();', False )
> #add_registration_code is documented
>
> However it will not help you :-(, boost 1.42 gives the following error:
[snip]
> 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.

>     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?

>     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.

>
>     While we are on warnings topic, another thing I've noticed. Suppose
>     I have function referring std::vector<std::string> >, Py++ will
>     happily export this vector of strings but will give it ugly name. If
>     I want to rename it, I can explicitly find declaration .include()
>     and .rename() it. In this case however I start getting some weird
>     warnings:
>
>
> Why do you ".include()" it? I could be wrong, but you can just rename it
> and if you use it in your "interface", Py++ should happily expose it
> under that name. If not, check Py++ "hints" documentation. You have few
> ways to provide an alias to the class.

You are right, there is no need to .include it. I've ended up including 
it just because I have a table driven script which blindly includes and 
renames whatever listed in the table of classes. I've beefed up this 
logic a bit and now can avoid unnecessary .include, and as you predicted 
the warning disappeared. Thank you.

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

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.

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.

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

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?

Thank you so much for your support.

Cheers,

Kirill