Nikolai Pretzell wrote:
Hi Stephan and all,
The consensus back then was to keep -Wnon-virtual-dtor switched on
globally, and only switch it off (together with all other warnings)
within cppumaker-generated headers, on the grounds that
-Wnon-virtual-dtor was considered a useful tool to find errors.
However, trying to compile
cppuhelper/qa/propertysetmixin/comp_propertysetmixin.cxx, I fear we
have to rethink the case: cppu::PropertySetMixin is part of the
stable API of OOo/URE, is a class template, and contains a non-virtual
dtor and virtual functions. Since it is part of the stable API, we
cannot change its dtor to be virtual (and even if we could, one could
argue that that would not be what one would want to do, but consider
it a hack to work around the warning). And since it is a template, we
cannot disable the warning locally---the warning is emitted at the end
of each compilation unit that includes
cppuhelper/propertysetmixin.hxx, rather than from within
cppuhelper/propertysetmixin.hxx itself.
The only solution I see is to bite the bullet and globally disable
-Wnon-virtual-dtor.
Mhmm. Why not make the d'tor protected?
As for compatibility, there should be no binary difference.
The dtor is already protected. The problem is that changing a dtor from
non-virtual to virtual affects the vtable (with some compilers, at
least), so that calls through the vtable could fail after such an
incompatible change.
-Stephan
Only the use would be constrained, but if cppu::PropertySetMixin is
indeed used as a mixin, then in most cases (whenever it is not the first
base class or any other base class is virtual, may be even whenever it
is not the only base class) calling its d'tor directly would be a bug
anyway.
So maybe this does not break practical compatibility?
You mentioned somewhere else, that making non-virtual d'tors protected
does not solve the problem of the warning. But as it solves the defect,
may be later versions of the compiler will not complain anymore?
So we would at least keep the option to switch the warning on in future.
Nikolai
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
