On 9/22/11 5:33 PM, "ext Thiago Macieira" <[email protected]> wrote:
>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.
Fully agree with Thiago. Making signals private would break an awful lot
of existing code and is in many cases very inconvenient.
I would also prefer if we could continue keeping signals protected, but as
Olivier pointed out there are lots of advantages with the new connect
syntax.
Cheers,
Lars
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
