[C++-sig] [Py++] shared_ptr registration
Hello Roman/All,
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?
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? Is client expected to
manually add calls to bp::register_ptr_to_python, or is it something
Py++ supposed to do automagically? Is there any way to force Py++ to add
such registration?
Here is a promised example:
-
#include
class foo1;
typedef boost::shared_ptr foo1_ptr_t;
class foo1
{
public:
foo1_ptr_t parent() const{return foo1_ptr_t(new foo1);}
};
class foo2;
typedef boost::shared_ptr foo2_ptr_t;
class foo2
{
public:
virtual ~foo2() {}
foo2_ptr_t parent() const{return foo2_ptr_t(new foo2);}
};
--
As you can see there are two slightly different cases. The only
difference is that foo2_ptr_t is a pointer to const foo2. However from
Python I can only call foo1::parent, foo2::parent fails with "No
to_python (by-value) converter". The code generated by Py++ is:
--
{ //::foo1
typedef bp::class_< foo1 > foo1_exposer_t;
foo1_exposer_t foo1_exposer = foo1_exposer_t( "foo1" );
bp::scope foo1_scope( foo1_exposer );
{ //::foo1::parent
typedef ::foo1_ptr_t ( ::foo1::*parent_function_type )( )
const;
foo1_exposer.def(
"parent"
, parent_function_type( &::foo1::parent ) );
}
bp::register_ptr_to_python< boost::shared_ptr< foo1 > >();
}
bp::class_< foo2 >( "foo2" )
.def(
"parent"
, (::foo2_ptr_t ( ::foo2::* )( ) const)( &::foo2::parent ) );
--
Why code is so different for these two cases?
Why foo2 doesn't have bp::register_to_python?
During code generation I get W1040 warnings saying that
"shared_ptr 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. Why the warning is generated
for foo1?
While we are on warnings topic, another thing I've noticed. Suppose I
have function referring std::vector >, 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:
WARNING:
std::basic_string,std::allocator > *
std::vector >::data() [member
function]
> compilation error W1050: The function returns
"std::basic_string,std::allocator > *"
type. You have to specify a
> call policies.Be sure to take a look on `Py++` defined call policies
WARNING:
std::basic_string,std::allocator >
const * std::vector >::data()
const [member function]
> compilation error W1050: The function returns
"std::basic_string,std::allocator >
const *" type. You have to specify
> a call policies.Be sure to take a look on `Py++` defined call policies
Regards,
Kirill
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] py++ site down? Project moved?
Hi, has py++ moved somewhere else? This seems to be unreachable: http://language-binding.net/pyplusplus/pyplusplus.html Regards Holger Landesbank Baden-Wuerttemberg Anstalt des oeffentlichen Rechts Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz HRA 12704 Amtsgericht Stuttgart ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] py++ site down? Project moved?
On Tue, May 17, 2011 at 5:04 PM, Holger Joukl wrote: > > Hi, > > has py++ moved somewhere else? > > This seems to be unreachable: > > http://language-binding.net/pyplusplus/pyplusplus.html I just redirected "language-binding.net" to http://sourceforge.net/projects/pygccxml/ . It will take some time until the change will be distributed among DNS's. The Py++ site consisted from the documentation and adsense. I remove the latest one and put the updated documentation at: http://sourceforge.net/projects/pygccxml/files/docs-pygccxml-pyplusplus/docs-Mar-17-2011.zip/download HTH ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] shared_ptr registration
On Tue, May 17, 2011 at 4:48 PM, Kirill Lapshin 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::holds(boost::python::type_info, bool) [with Pointer =
boost::shared_ptr, 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
> 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. 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 >, Py++ will happily export this
> vector of strings but will give it ugly name. If I want to rename it, I can
> explicitly find declara
