What about little help with signals and slots checking?
-
bq. Oh my… This looks complicated.
I just suggest force MOC do check job and extend new keywords as it did in class declarations. Very small additions and clear syntax…On the contrary, the syntax though complex is actually following the new industry standards in C++, similar syntax is used in another popular C++ library "Boost" too, and is trying to be in sync with the C++ standards committee. So as a standard, it makes it easier for coders to recognize and understand it. It also provides compile-time checking.. not to mention inlines in C++0x and many small neat things. So it's all good!
-
bq. How does the MOC know which signal to use if there are multiple overloaded signals?
if there is more than one matching pair - it can break with error, then syntax can allow parameter type names after method name
bq. If there method 1 is overloaded how does the MOC know which method to use
answer is the same - error message with ability add type names
@static SOCKETINFO socketz[] = {
{ "Output-1", signal class1 method1 int, float, Qt::AutoConnection, true },
{ "Input-1", slot class1 method2, false, Qt::AutoConnection }
};@if there are method1(int) and method1(int,float) then error message again - you have point type names completely to not confuse MOC
in connection it can be done once:
@connect( signal class1 this method1 int float, slot class2 other method2 );
that means error if method2(int,float) is not declared in class2
-
If you are seriously aware about "syntax standard" - it can be:
@static SOCKETINFO socketz[] = {
{ "Output-1", signal class1::method1( int, true ), Qt::AutoConnection, true },
{ "Input-1", slot class1 method2, false, Qt::AutoConnection }
};@
and@connect( signal (class1)this::method1( int, float ), slot (class2) other::method2 );@
but the idea assumes it is compatible to already created applications
-
The new syntax is supposed to be an addition to the existing one. At least that is what was said at QtCS.
-
That's good. That means my suggestion does not intersect with new syntax. They can exist both. MOC additions should be made only by MOC developer(s) and only in MOC. It could appear for Qt4 and be further used in Qt5. Programmer will choose what is better for him.
-
I wonder what a C++ compiler does with your syntax. To me it looks like it will consider the connect statement a syntax error and bail out. The compiler needs to parse the code as well as moc.
-
bq. I wonder what a C++ compiler does with your syntax.
The C++ compiler must not see that! After MOC it should be the conventional C++ syntax with present SIGNAL() and SLOT() macros!
@static SOCKETINFO socketz[] = {
{ "Output-1", signal class1::method1( int, true ), Qt::AutoConnection, true },
{ "Input-1", slot class1::method2, false, Qt::AutoConnection }
};@
MOC shout turn to
@static SOCKETINFO socketz[] = {
{ "Output-1", SIGNAL(measuredValue( float )), true, Qt::AutoConnection, true },
{ "Input-1", SLOT(activateMeasure( int )), false, Qt::AutoConnection }
};@and
@connect( signal (class1)this::method1( int, float ), slot (class2)other::method2 );@
to
@connect( (class1)this, SIGNAL(method1( int, float )), (class2)other, SLOT(method2( int, float )) );@
but if only matching method2( int, float ) declared in class2 -
The point is, MOC does create source code and is no pre processor for the c++ compiler. so C++ compiler would see
@
connect( signal (class1)this::method1( int, float ), slot (class2)other::method2 );
@which can't be simply mapped with #defines.
@
connect( this, SIGNAL(method1( int, float )), other, SLOT(method2( int, float )) );
@will be expanded by the pre processor to
@
QObject::connect(this, "1method1( int, float )", other, "2method2( int, float )");
@Using this method, you can event connect QObject pointers without knowing the real implementation class. With your syntax it is mandatory to know them inside the class doing the connect, which means connect on QObject pointer is only possible for QObject slots/signals.
On the other side, the new sysntax is not complex, it's just C++ standard (pointer to member) and STL. This is nice, as this is also standard.
-
No, MOC can't work as pre provcessor. This would mean to modify the build chain, as pre processor creates an intermediate file used by the processor. If moc should work as pre processor, it must create the first intermediate file, which is then processed by the pre processor of the used build chain, which also means to modify the make file syntax to something, noone will understand.
It makes no sense from my POV.
-
[quote author="Gourmand" date="1308685686"]Hm... are there still any people who looks at automatically generated makefiles?... :-D[/quote]
That would be me.The thing that really worries me about the new syntax is the fact that encapsulation is broken. That isn't all that good from my point of view. Signals and slots traditionally helped in decoupling and encapsulation. It would be a shame to throw that away to support a new syntax that only has local advantages. I do like the non-blocking open file example, but if it means breaking a lot of goodness, I rather write a slot or two instead.
Overloading of slots is probably going to be discouraged according to the doc, which is rather useless if you want to keep the "normal class function with added calling possibilities".
-
[quote author="Gerolf" date="1308722120"]If I understood correctly, old and new syntax should work, so that would mean, old stuff will go on working, and decoupling also.[/quote]
True that. The encapsulation is achieved by keeping the signals protected, which has to be changed for the new syntax to work. To be honest, that still sounds like a deal-breaker to me. -
I agree with Franzk on the worry about breaking encapsulation (especially the example about having a public aboutToQuit signal which can then called/emitted from another class!). But i'm positive, they will find a solution for that.
-
Encapsulation is already broken with signals and slots. I don't see how making the signals public will break it more than it already is. Even now, you can use this to trigger a signal in another object:
@
QMetaObject::invokeMethod(theOtherObject, "myDangerousSignal", Q_ARG(bool, m_selfDestruct));
@Making the signal public will make the above a bit easier, but the effect won't be any different:
@
theOtherObject->myDangerousSignal(m_selfDestruct);
@Same goes for slots, by the way. They are open to the public if a user really wants to, even the ones you declared as private.
Bottom line for me: there needs to be careful consideration if making the signals public is worth the benefit. Making them public may send the wrong message in terms of API design, but the actual protection of the methods does not change. That makes it, in my eyes, not a deal-braker if the benefits are great enough.