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.
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]