gcc -Woverloaded-virtual

[David Faure]

On Wednesday 21 November 2007, Thiago Macieira wrote:
> Em Wednesday 21 November 2007 16:18:37 David Faure escreveu:
> > On Wednesday 21 November 2007, Matthias Kretz wrote:
> > > On Wednesday 21 November 2007, David Faure wrote:
> > > > What we're missing is a way to say "yes I wanted to hide this method
> > > > from the base class"...
> > >
> > > Hiding a method from a base class is not possible anyway as you can still
> > > cast down and then call the method. It kind of works for value based
> > > classes since those are normally not casted down, but for all
> > > pointer-based (i.e. QObject) classes I believe you should not hide a
> > > method and get a warning if you do (also for non-virtual functions).
> >
> > Well that's the theory :)
> > In practice the base class method doesn't always make sense. Example:
> >
> > /d/kde/src/4/kdelibs/kdeui/actions/kselectaction.h:217: warning: ‘virtual
> > void KSelectAction::addAction(QAction*)’ was hidden
> > /d/kde/src/4/kdelibs/kdeui/actions/krecentfilesaction.h:98: warning:   by
> > ‘void KRecentFilesAction::addAction(QAction*, const KUrl&, const QString&)’
> >
> > Sure you could call KSelectAction::addAction even on a KRecentFilesAction,
> > but you don't want to... you want to associate a url with the action. This
> > is documented, too. /**
> >    * Adds \a action to the list of URLs, with \a url and title \a name.
> >    *
> >    * Do not use addAction(QAction*), as no url will be associated, and
> >    * consequently urlSelected() will not be emitted when \a action is
> > selected. */
> >   void addAction(QAction* action, const KUrl& url, const QString& name);
> >
> > So here the hiding is good... it's actually an example of why the hiding
> > feature exists in the first place...
> 
> Matthias's point here is that you *still* can call addAction(QAction*). The  
> hiding is only partially complete: anyone keeping a pointer to KSelectAction 
> will be calling the wrong function.
I know. But nobody does that :-)  -- I warned that I'm talking about practice here :)

> If the base class's function is not wrong, then it should be unhidden by using 
> using. If it is wrong, it should be reimplemented.
The base class function is wrong because its signature is incomplete. Therefore none
of your two proposal work... We don't want to unhide it, and we can't reimplement it
either since it would miss a very important piece of information: the url for this action.

A private "using" clause is a solution (which doesn't solve the "KSelectAction*" issue,
but there is no real solution to that one, except a reimplementation that warns or aborts...
still not caught at compile time though).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).