Re: -Wno-non-virtual-dtor

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@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@lists.freedesktop.**org <LibreOffice@lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/libreoffice<http://lists.freedesktop.org/mailman/listinfo/libreoffice>



-- 
Arnaud Versini