On Thu, May 19, 2011 at 4:23 PM, Kirill Lapshin 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
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
