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 <boost/shared_ptr.hpp>
class foo1;
typedef boost::shared_ptr<foo1> foo1_ptr_t;
class foo1
{
public:
foo1_ptr_t parent() const{return foo1_ptr_t(new foo1);}
};
class foo2;
typedef boost::shared_ptr<const foo2> 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<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?
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:
WARNING:
std::basic_string<char,std::char_traits<char>,std::allocator<char> > *
std::vector<std::string, std::allocator<std::string> >::data() [member
function]
> compilation error W1050: The function returns
"std::basic_string<char,std::char_traits<char>,std::allocator<char> > *"
type. You have to specify a
> call policies.Be sure to take a look on `Py++` defined call policies
WARNING:
std::basic_string<char,std::char_traits<char>,std::allocator<char> >
const * std::vector<std::string, std::allocator<std::string> >::data()
const [member function]
> compilation error W1050: The function returns
"std::basic_string<char,std::char_traits<char>,std::allocator<char> >
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
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
