Solved connect() new style syntax return result

[J.Hilk]

@JonB
well, take this example:

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    QLineEdit e;
    QLabel *l;
    QMetaObject::Connection c = QObject::connect(&e, &QLineEdit::textChanged, l, &QLabel::setText);

    qDebug() << c;

    return a.exec();
}

it compiles fine, but connection fails, because the QLabel does technically not exist during the connect call

[JonB]

@J-Hilk
Yep.

In that case, I want to see all the code you have ever written even with the new style syntax where, as a good citizen, you run-time check the return result of every connect() you ever perform? And a promise that you never fail to do so?

[J.Hilk]

@JonB :P

sure, no it's the only case that I can think of, where the connect "could fail"
you asked for any case 😉

[JonB]

@J-Hilk
I asked an intentional question: I know you to be a good citizen, so do you check all your new-style connect()s at runtime? I should like to know....

[J.Hilk]

@JonB said in connect() new style syntax return result:

so do you check all your new-style connect()s at runtime?

tbth
not a single one😅

[JonB]

@J-Hilk
Exactly ;-)

Though from now on I shall be strongly recommending it for those who insist on old-style, run-time behaviour.

Other than your (correct) example, can you think of any others, assuming the signaller/slotter are, say, correct? I'm trying to understand whether there is anything during the (new style) connect() which could still fail, even if my code looks right?

[J.Hilk]

@JonB I'm not sure in the case of custom argument types (enums, classes etc) when you send them via Qt::QueuedConnection I think those will also fail silently, If you failed to correctly register the types with the meta system.

If you forget a copy constructor for your custom class you should get a completive error

[JonB]

@J-Hilk
Thanks, I'll keep this open for a day or so, in case it inspires interesting comments when the other experts finally get out of bed :) I can't believe they would ever fail to check a return result which might fail......

I now feel "unclean" with all my existing connect() code :( I hadn't even looked at the return result, all the examples out there and what is posted on this forum never bother so I hadn't investigated....

[J.Hilk]

@JonB aren't you glad that c++17 introduced [[nodiscard]]

😉 I'm, but I doubt QObject::connect will ever geht that attribute, but could be fun for a April fools joke, to submit such a patch 🤣

[KroMignon]

@JonB said in connect() new style syntax return result:

I know you to be a good citizen, so do you check all your new-style connect()s at runtime? I should like to know....

If you are using new-style connect(), the return value is not that relevant.
The only interesting use case I see, is to use it to disconnect a specific slots/lambda function.

[JonB]

@J-Hilk
Excellent! I'm sure all existing code would welcome this attribute being auto-added ;-)

[JonB]

@KroMignon
Indeed! Nonetheless, @J-Hilk's example of an uninitialized variable might have been picked up. Though I suppose you will say we can never guard against, say, bad variables in this way....

Being an old C programmer, perhaps I should define connect() as a macro with a Q_ASSERT wrapper or similar on the return result...? ;-) [<-- Note the "wink", I am aware what you will think of that :) ]

[KroMignon]

@JonB said in connect() new style syntax return result:

Being an old C programmer, perhaps I should define connect() as a macro with a Q_ASSERT wrapper or similar on the return result...? ;-) [<-- Note the "wink", I am aware what you will think of that :) ]

I am also a far older (embedded) C programmer as a C++ programmer ;-)
But I am not sure this is the best idea for checking connect() return value...

[JonB]

@KroMignon said in connect() new style syntax return result:

But I am not sure this is the best idea for checking connect() return value...

It is when you don't want to change any lines of code, other than adding one #define :)

[Pablo J. Rogina]

@JonB said in connect() new style syntax return result:

Certainly if people insist on using the old-style SIGNAL/SLOT() macros

One of the things I see regarding old-style approach, is the lots and lots of examples still around using it. So for newcomers to Qt, having that available to start with is somehow misleading...

[J.Hilk]

@Pablo-J-Rogina
there's almost no situation where the qt5 syntax wouldn't work as well, so maybe marking it as deprecated could be an option. 🤷‍♂️

[JonB]

@Pablo-J-Rogina
Exactly. Hence I often evangelise with noobs to get changed over. I realize it's hard with all the examples being old-style, and somehow they find new style --- (and lambdas) --- trickier. But judging by some of the answers where their old-style connect is wrong but they don't know it is till runtime problems, I think it will help them to move to new because they get compile-time error and importantly they get auto-completion of only suitable methods to use.

[Pablo J. Rogina]

@J-Hilk said in connect() new style syntax return result:

there's almost no situation where the qt5 syntax wouldn't work as well,

Please don't misunderstand me. I'm in full favor of the new syntax, the compile time checking is a great advantage.

marking it as deprecated could be an option

That would be great! Do we need to create a feature request?

[KroMignon]

@Pablo-J-Rogina said in connect() new style syntax return result:

That would be great! Do we need to create a feature request?

I don't agree with this!
There are some situation where using old syntax has advantages.
For example, suppose you have some classes with implements QObjects which all have a slot void doWork(void), you could connect to this slot without having to know from which class the instance is based.
That's not possible with new syntax, also slots overload handling is not so easy to use.
I agree that overloading slots is not a good code practice.

[SGaist]

And IIRC, the "old" system is also what allows for things like QML to work its magic.

The porting of the example is a good idea. The documentation team would be happy to get some help with that so you are more than welcome to submit patches. I think there are tasks related to that on the bug tracker to help organise.