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<const foo2> 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<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.
Ok, that is done now. I also went ahead and opened a bug (or rather a
wishlist) for shared_ptr<const foo> 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<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.
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
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
