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 (760e0d2d7329ca6fc00a8439715bae38becb168a ), 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 , 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. (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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
