On Wed, May 18, 2011 at 5:06 PM, Kirill Lapshin <k...@lapshin.net> 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<const foo2> 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<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. 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 Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
