-Wno-non-virtual-dtor
Arnaud Versini
arnaud.versini at gmail.com
Tue Mar 13 11:11:11 PDT 2012
I'm also on it after the RTF patch pushed sunday (
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f32fe9f5012e3ee184e1a1fca6814bee9105d8fb),
the patch for WW8ResourceModel.hxx will be avaible this evening.
Thanks
Le 13 mars 2012 15:11, Stephan Bergmann <sbergman at redhat.com> a écrit :
> On 03/13/2012 03:00 PM, Lubos Lunak wrote:
>
>> On Tuesday 13 of March 2012, Stephan Bergmann wrote:
>>
>>> On 03/13/2012 11:43 AM, Tor Lillqvist wrote:
>>>
>>>> Hmm, now that the reason for using -Wno-non-virtual-dtor has been
>>>> documented (**760e0d2d7329ca6fc00a8439715bae**38becb168a ), I wonder,
>>>> should we globally then also turn off the corresponding MSVC warning?
>>>>
>>>> That would be kinda predictable (from a "the usual waste of time"
>>>> point of view), as I and others have committed over times dozens of
>>>> WaE fixes for this very issue... (I.e. added a virtual no-op
>>>> destructor in most cases).
>>>>
>>>> Or does gcc and MSVC warn for different cases of lack of virtual
>>>> destructor? Is it certain that in all cases this warning is bogus, in
>>>> both the gcc and MSVC cases?
>>>>
>>>
>>> I think the warning is generally non-bogus. The problem is that we were
>>> not able to change the cppumaker-generated C++ headers without breaking
>>> backwards compatiblity[1], and GCC was somewhat over-ambitious with this
>>> warning[2], so had to disable it -- even if we would have preferred to
>>> keep it on.
>>>
>>
>> The original message about the problem,
>> http://markmail.org/message/**664jsoqe6n6smy3b<http://markmail.org/message/664jsoqe6n6smy3b>, mentions that it is not
>> possible to selectively disable the warning for just the classes where we
>> need to keep the binary compatibility.
>>
>> Assuming that my attached testcase correctly matches the problem, I do
>> not
>> see a warning with either gcc-4.6.3 or clang-3.1r152540. So it looks like
>> we
>> can either just enable the warning and selectively disable it, or we can
>> have
>> a configure check if some older gcc version has the problem (well, given
>> that
>> #pragma diagnostic is recent with gcc, it'll need an #ifdef anyway).
>>
>> $ g++ -Wall dtor.cpp -Wnon-virtual-dtor -c
>>
>
> I'm going to add protected, non-virtual dtors to the problematic classes.
> That's backward compatible (not 100%, in that it prevents deletes of
> objects through pointers to those non-virtual-dtor classes, but those are
> actually bugs, anyway) and clean, and no longer causes -Wnon-virtual-dtor
> warnings with recent GCCs.
>
> With that in place, we can re-enable -Wnon-virtual-dtor in
> solenv/gbuild/platform/unxgcc.**mk <http://unxgcc.mk>. (I planned on
> bluntly always enabling it there, which might cause problems for
> --enable-werror on platforms with old GCC versions. Basing enabling on a
> GCC version check or some configure check might indeed be better.)
>
>
> Stephan
> ______________________________**_________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.**org <LibreOffice at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/libreoffice<http://lists.freedesktop.org/mailman/listinfo/libreoffice>
>
--
Arnaud Versini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120313/088fce03/attachment.htm>
More information about the LibreOffice
mailing list