On Thursday, 22 de September de 2011 14:06:05 Olivier Goffart wrote:
> I almost managed to get the signal private:
>
>
> class Foo {
> public:
> class Signal { //This would be in the Q_OBJECT macro.
> ~Signal() {}; // private destructor
Q_DISABLE_COPY(Signal)
> friend class Foo; //<- problem: Q_OBJECT macto does not know "Foo"
> };
>
> Signal bar(); //New way of declaring signals, moc detect the return type
> };
>
> int main()
> {
> Foo::Signal (Foo::*sig)() = &Foo::bar; // works
> Foo f; f.bar(); // error, ~Signal is private
> return 0;
> }
>
>
> But this mean signals are now private instead of protected (which i think is
> maybe a good thing) and that Q_OBJECT should be changed to know which
> class it it in so it can put the friend.
That requires changing every single header defining a QObject-derived class. It
might be automatable, but I'm not sure it will catch every case.
Making signals private is IMHO much worse than making them public. Take for
example signal QIODevice::readyRead(): it's emitted from almost all classes
deriving from QIODevice (notable exception is QFile). In order to fix that
case, we'd need to add a signal-emitting function. But in any case, this is
way source-incompatible and I doubt it is automatable at all.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
