After resyncing CWS warnings01 to SRC680m138, we found the following
problem:
cppu::WeakComponentImplHelper1--12 (cppuhelper/compbase1--12.hxx) now
explicitly define functions dispose, addEventListener, and
removeEventListener to forward to WeakComponentImplHelperBase (the
rationale being that if WeakComponentImplHelperXX is instantiated for an
interface that inherits XComponent, you do not want to force the client
to redefine those functions to get rid of the pure virtual ones,
similarly to the functions of XInterface).
However, if now WeakComponentImplHelperXX is instantiated for an
interface X that has any functions named dispose, addEventListener, or
remvoeEventListener (that are different from the functions of
XComponent), the Solaris C++ compiler will warn that the explicitly
defined functions above shadow any of the functions of X. A using
declaration would be needed, but it cannot be injected into
WeakComponentImplHelperXX just for those instantiations that need it (at
least, I could not think of a solution).
And there are at least four UNO interface types that have methods with
problematic names: css.uno.XReference has a method named dispose, and
css.document.XEventBroadcaster, css.xml.dom.events.XEventTarget, and
css.accessibility.XAccessibleEventBroadcaster each have methods named
addEventListener and removeEventListener (of them,
css.xml.dom.event.XEventTarget is not yet published---Lars, how about
renaming those methods?). (And there are at least 16 files in the OOo
C++ code base that mention both WeakComponentImplHelperXX and one of the
problematic UNO interfaces, i.e., which potentially use the problematic
scenario, so I do not think it is an option to forbid combining
WeakComponentImplHelperXX with a problematic interface.)
I solved that problem for now by disabling warnings (for the Solaris C++
compiler only) around the definitions of WeakComponentImplHelperXX. I
think cases are rare enough where one of the shadowed functions would be
called directly on an instantiation of WeakComponentImplHelperXX
(instead of via the corresponding interface type) to disable the
(otherwise quite instructive) warning here.
Anyway, if you can think of a better solution, please let me know.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
