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