On Thursday, May 19, 2011 04:57 AM, Roman Yakovenko wrote:
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.
That's great, no pressure, I can register them manually for time being.
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)
Fair enough, it is not a big deal and easy to handle in client code. I
don't necessarily agree with your point though. To me the whole wrapper
business is implementation detail. Unless I'm missing something it
doesn't really matter how wrapper class called, as long as name unique.
It would be fairly simple to handle in Py++. In a sense Py++ already
goes to great length to detect when wrapper names are not unique and
generate warning. Suppose for argument sake Py++ would generate
sequential wrapper names, e.g. wrapper1, wrapper2, etc. It would
simplify Py++, as there would be no need to detect wrapper name clashes
and report warnings. It would make generated code less readable, but
with a bit more elaborate naming scheme for wrapper that could be fixed
too. Anyways, as I said, I don't have problem with handling it on my
side, just sharing my thoughts.
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.
Makes perfect sense, now what could be done to avoid this warning, other
than just disabling the warning? For instance is there a way to tell
Py++ hey, look, this method doesn't have to be (or shouldn't be)
overrideable in Python?
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?
Didn't have a chance to create an example today. Will try to post one
tomorrow. I'm using gcc 4.4 on Red Hat.
All the best,
Kirill
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
