Qt 4.6 behaves differently when "overloading" signals

[Friedrich W. H. Kossebau]

Samedi, le 7 novembre 2009, à 19:19, Thiago Macieira a écrit:
> Em Sábado 7. Novembro 2009, às 18.26.48, Dario Freddi escreveu:
> > On Saturday 07 November 2009 18:19:44 you wrote:
> > > That warning and behaviour is about 5 or six years old. I asked thiago
> > >  about it some weeks before. You only see it now because it only
> > > appears in qt developer builds which we only started to use when
> > > switching to the qt git repo.
> > >
> > > So i think the ... it worked with qt <4.6 may be unlikely. Are you
> > > really sure?
> >
> > Sure, otherwise for example the k3bsetup and some other polkit-qt
> >  applications wouldn't work as expected with qt 4.5.
>
> The warning is correct.
>
> Overriding signals is an extremely bad idea. Since signals aren't virtual,
> the code in the base class that emits the signal will emit the lower-ID
> signal. However, the connect() call searches from the most derived class
> towards QObject -- that means you connect to the most-derived class's
> signal.
>
> In other words, the signal is emitted, but it's never caught.
>
> DO NOT override signals.

Related to this:
Has it ever been considered to make it possible to add signals to abstract 
interfaces? Such that a class implementing this interface has this signal?

In Okteta/Kasten I currently use a hack I have seen somewhere else (don't 
remember where) by adding the signal as abstract method to the interface, 
like
	virtual somethingChanged() = 0;
so the compiler will enforce a developer to also define this signal in the 
class using implementing the interface.
	Q_SIGNALS:
	virtual somethingChanged();
Since Qt 4.6 (IIRC) moc complains about this
	Warning: Signals cannot be declared virtual
but it can be fooled by just leaving out the redundant "virtual" keyword in 
the class declaration, keeping the signal method still virtual.

Now it would be great if I could add something like
	Q_SIGNAL_NEEDED( somethingChanged() )
or similar to the abstract interface, which moc will read* and, instead of the 
compiler, check if the signal is declared in the class implementing this 
interface and complain/stop if not. So I (and others) can get rid of this 
hack :)

*Does moc also parse the included headers?

Thanks
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta