On Thu, May 19, 2011 at 4:23 PM, Kirill Lapshin <k...@lapshin.net> wrote:
> 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. > Thanks for sharing. The "wrapper class" is a part of the interface, that's why in my opinion, its name is very important and the developer should spend few more minutes to name them properly. I think, we can add a new flag to module_builder_t, so it would generate unique name for every class. If you like the idea, please open a ticket :-) > > 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? Unfortunately you will have to disable the warning :-( HTH
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
