[C++-sig] [Py++] shared_ptr registration
kir at lapshin.net
Thu May 19 15:23:35 CEST 2011
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
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,
More information about the Cplusplus-sig