Qt 4.6 behaves differently when "overloading" signals

Olivier Goffart ogoffart at kde.org
Sun Nov 8 16:37:13 GMT 2009


Le Sunday 08 November 2009, Friedrich W. H. Kossebau a écrit :
> Pardon me, accidently sent before completing:

Is there a difference between the two mails?
 
> Dimanche, le 8 novembre 2009, à 15:22, Olivier Goffart a écrit:
> > 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.
> 
> The base class here is an abstract interface, so not a QObject, so the
>  signal can not be placed there.

Ok, now it makes sens to me.


[...]
> class Class : public QObject, public DataContainer
> {
>   Q_OBJECT
>   Q_INTERFACES( DataContainer )
>   public:
>     virtual Data data() const;
>     virtual void setData( const Data& data );
>   Q_SIGNALS:
>     virtual void dataChanged( const Data& data );
> }

You can omit the keyword 'virtual' there, and then moc will not output 
warnings.

The only problem is that someone could forget the Q_SIGNALS keyword in the 
reimplementation.  Then there will be a warning at runtime saying "signal not 
found"

> I would prefer:
> class DataContainer // abstract interface
> {
>   public:
>     virtual ~DataContainer();
>   public:
>     virtual Data data() const = 0;
>     virtual void setData( const Data& data ) = 0;
> 
>     Q_ABSTRACT_SIGNAL(dataChanged( const Data& data ))
> }
> 
> class Class : public QObject, public DataContainer
> {
>   Q_OBJECT
>   Q_INTERFACES( DataContainer )
>   public:
>     virtual Data data() const;
>     virtual void setData( const Data& data );
>   Q_SIGNALS:
>     void dataChanged( const Data& data );
> }
> 
> Moc would see there should be a signal "dataChanged( const Data& )" and
>  checks if the class implementing the interface also has this.

This is indeed a good idea. But it would add very little for the changes it 
requires.






More information about the kde-core-devel mailing list