Re: [C++-sig] [Py++] shared_ptr registration
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 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 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.
Ok, that is done now. I also went ahead and opened a bug (or rather a
wishlist) for shared_ptr 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 >, 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
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] shared_ptr registration
On Wed, May 18, 2011 at 5:06 PM, Kirill Lapshin wrote: > On 18/05/2011 04:27, Roman Yakovenko wrote: >> >> 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 it compiles > fine with Boost 1.46.1 and works as expected. So I suppose your patch did get > applied. Cool. It looks like I have to fix Py++. >> 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? Yes of course. I'll fix this bug, but it will not happen this or next week so. >> 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. > > Ok, that is done now. I also went ahead and opened a bug (or rather a > wishlist) for shared_ptr support as well. Hope you don't mind. The opposite - it is very good. If Py++ will report a lot of irrelevant warning, the user will skip them, and the goal will not be achieved. I will try to fix it too. > In the meantime I've got few more questions for you, if you don't mind. I don't :-) > 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. I understand why you are asking for this, but somehow I feel that this functionality doesn't belong to Py++. The functionality could be easily implemented by the user. You can use "partial_decl_string" or "decl_string" properties for this purpose. "partial_decl_string" - returns fully resolved name ( '::ns1::ns2::klass ), without default template arguments (for known classes of course, mainly from std) > 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. This warning is reported for virtual functions (please confirm). Consider, virtual or pure virtual function "wrapper" implementation (the one you define in a class, which derives from boost::python::wrapper), for a class implemented in Python. Boost.Python don't have a place to store "std::string". You call the function, get the result, which lives on stack and then you return it. Once you exit the function, your std::string class instance is destroyed. I suggest you to try a simple example and analyze it. > The last question I have (at least for now :) ) is: It's okey > 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? I would like to see the example and to know what compiler do you use. Even, in case Py++ doesn't have this functionality, you can change the function alias to "__DoNotCallThisFunctionXYZ" and use "override_precall_code" and "default_precall_code" functionality (see docs and/or tests) to add a code, which will throw exception. Could this help to solve your problem? > Thank you so much for your support. You are welcome. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
