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

[Roman Yakovenko]

On Tue, May 17, 2011 at 4:48 PM, Kirill Lapshin <kir at lapshin.net> wrote:

> Hello Roman/All,
>

Hello.


> I used Py++ before, and was very happy with it, now I'm working on a new
> project and trying to introduce Py++ here as well. Naturally I decided to
> get a latest version (was using a bit outdated version before), and noticed
> that there was no release in quite some time, so here is a first question:
>
> - I've seen a message on this list from Mar 25 saying that project is alive
> and kicking -- that was quite a relief. Any plans for new release?
>

Not in a few next months. The SVN contains tested and documented version. It
is perfectly save to use it.


>
> I've ran into some problems with 1.0, as in Py++ failed with traceback
> during code generation, so decided to give latest trunk a go (using r1856
> atm). This one worked quite a bit better, but I'm running into some
> weirdness around shared_ptr registration. The codebase I'm wrapping uses
> them heavily, and for whatever reason some of them get registered, while
> others not, and any attempt to for example call a function returning such
> unregistered shared_ptr unsurprisingly results in "No to_python (by-value)
> converter" error. I've reproduced this problem on small example. Before we
> go there though I'd like to formulate another question:
>
> - How shared_ptr registration supposed to work?


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.


> Is client expected to manually add calls to bp::register_ptr_to_python, or
> is it something Py++ supposed to do automagically?


Automagically :-)
*
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/smart_pointers_to_be_exported.hpp?revision=1837&view=markup
*
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/data/smart_pointers_to_be_exported.cpp?revision=1837&view=markup
*
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/unittests/smart_pointers_tester.py?revision=1837&view=markup



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

In file included from /usr/include/boost/python/to_python_indirect.hpp:10:0,
                 from
/usr/include/boost/python/converter/arg_to_python.hpp:10,
                 from /usr/include/boost/python/call.hpp:15,
                 from /usr/include/boost/python/object_core.hpp:12,
                 from /usr/include/boost/python/args.hpp:25,
                 from /usr/include/boost/python.hpp:11,
                 from smart_pointers.cpp:8:
/usr/include/boost/python/object/pointer_holder.hpp: In member function
'void* boost::python::objects::pointer_holder<Pointer,
Value>::holds(boost::python::type_info, bool) [with Pointer =
boost::shared_ptr<const smart_pointers::maybebug::foo2>, Value = const
smart_pointers::maybebug::foo2]':
smart_pointers.cpp:500:1:   instantiated from here
/usr/include/boost/python/object/pointer_holder.hpp:145:66: error: invalid
conversion from 'const void*' to 'void*'
/usr/include/boost/python/object/pointer_holder.hpp:145:66: error:
initializing argument 1 of 'void*
boost::python::objects::find_dynamic_type(void*, boost::python::type_info,
boost::python::type_info)'
/usr/include/boost/python/object/pointer_holder.hpp:145:66: error: invalid
conversion from 'const void*' to 'void*'
scons: *** [smart_pointers.os] Error 1
scons: building terminated because of errors.
ERROR

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.


Here is a promised example:
> ...
>


> Why code is so different for these two cases?
>

As you can guess already, this is because of "shared_ptr< const ... >"


> Why foo2 doesn't have bp::register_to_python?
>

Mainly because Boost.Python doesn't support it and/or Py++ doesn't recognize
it.


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



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

HTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20110517/4694232e/attachment-0001.html>