On Tue, May 17, 2011 at 4:48 PM, Kirill Lapshin <k...@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
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
