Qt 4.6 behaves differently when "overloading" signals

[Olivier Goffart]

Le Sunday 08 November 2009, Friedrich W. H. Kossebau a écrit :
> 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;

What would be the reason for doing that at all?
Remember the signal are normal methods implemented by the moc.
Wether the implementation is in the base class or in the derived class does 
not matter. So better to keep it in the base class.

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

The warning was actually an error in 4.5, but the error was not thrown often 
because of a bug in moc (fixed in e43eae35)

> 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 :)

again, it is fine to have the signal in the base class.  Signal are protected, 
derived class can emit it.
 
> *Does moc also parse the included headers?

Yes, provided that you give the include paths to moc (option -I)