Solved A console application doesn't support some classes.
-
In console application some includes give me errors
#include <QUdpSocket>
#include <QAbstractSocket>error: 'QUdpSocket' file not found
error: 'QAbstractSocket' file not found#include <QElapsedTimer>
QElapsedTimer timer; - error: unknown type name 'QElapsedTimer'Is it impossible to use these classes in console application ?
-
@jenya7 did you add QT += network and QT += core?
-
-
@jenya7 It is always good to check documentation: https://doc.qt.io/qt-5/qudpsocket.html
"qmake: QT += network" -
Oh, sorry. Completely forgot to include it in *.pro.
One more question - if I need a real time operation, like milliseconds execution time - is it better to set aside Object paradigm and write in old school C style? -
@jenya7 said in A console application doesn't support some classes.:
if I need a real time operation, like milliseconds execution time - is it better to set aside Object paradigm and write in old school C style?
you will be hard pressed to get that working with an operating system/thread scheduler sitting between your code and the hardware.
-
one more question
connect(socket, &QUdpSocket::readyRead, this, &UDP_ReadyRead);
I get - error: invalid use of 'this' outside of a non-static member function
UDP_ReadyRead should be a member of Object (class)? No other way to connect?
-
@jenya7 said in A console application doesn't support some classes.:
connect(socket, &QUdpSocket::readyRead, this, &ClassWithSlot::UDP_ReadyRead);
Connect syntax doesn't look correct. See that I added the "ClassWithSlot::"
-
@MrShawn
I see. So it should be a class.
And without a class - is there any way to invoke &QUdpSocket::readyRead event? -
@jenya7
Hi
Yes it must be a class to have "this", however, you can
use lamdas as a slot
https://wiki.qt.io/New_Signal_Slot_Syntaxsee section "Asynchronous made easier"
QObject::connect( socket, &QTcpSocket::readyRead, [socket]() { qDebug() << "GOT DATA " << socket->readAll(); } );
-
@mrjj
Wow. Thank you. That is goodThe new syntax can even connect to functions, not just QObjects: connect( sender, &Sender::valueChanged, someFunction );
-
Hi
If you not used lambdas before notice the special syntax[socket]
this means we capture that variable to the lambda so we can use it inside.
Since its a pointer (socket) that works fine. -
@mrjj
So it should be used as lambda?
Because this way it compilesQObject::connect(socket, &QUdpSocket::readyRead, &UDP_ReadyRead);
But I don't receive any messages.
On [socket] I get - error: 'socket' cannot be captured because it does not have automatic storage duration.
-
@jenya7 said in A console application doesn't support some classes.:
connect(socket, &QUdpSocket::readyRead, this, &UDP_ReadyRead);
I get - error: invalid use of 'this' outside of a non-static member function
UDP_ReadyRead should be a member of Object (class)? No other way to connect?This connect don't make sense to me.
If you want to connect a signal to a class method, you have to give fullname, including class name.
For example if you class is called MyMain:connect(socket, &QUdpSocket::readyRead, this, &MyMain:UDP_ReadyRead);
Or you can use a lambda function:
connect(socket, &QUdpSocket::readyRead, [this]() { qDebug() << "ReadyRead"; /// Do something useful } );
Take a look at documentation for more details: https://doc.qt.io/qt-5/signalsandslots-syntaxes.html
-
@KroMignon
Yes I see. But as I understand there is a new option available.The new syntax can even connect to functions, not just QObjects: connect( sender, &Sender::valueChanged, someFunction );
Doesn't it?
-
@jenya7 said in A console application doesn't support some classes.:
The new syntax can even connect to functions, not just QObjects:
Doesn't it?No, it doesn't!
You can connect with functor or lambda, not function
-
@KroMignon
I see. Thank you. -
@jenya7 said in A console application doesn't support some classes.:
is it better to set aside Object paradigm and write in old school C style?
First to be clear: don't use a C compiler. Even if you are writing procedural code use a C++ compiler. It is much stricter with types which helps you to catch many errors right away.
Also, don't give up on the object paradigm. Don't use it where you don't have to. Though, this is a general guideline: C++ is a multiparadigm language and you should use the best tool for the task, i.e. use objects where it makes sense, use generic programming where it makes sense, use procedural programming where it makes sense, etc. For object oriented programming there is the rule (if you are actually after performance): don't use
virtual
member functions if you don't have to. If you think you really have to use them then you would have to use function pointers in C instead. Usingvirtual
member functions instead the compiler can in some cases inline the call which it will not be able to do with function pointers. Basically, this means object oriented programming without much inheritance. Preferstd::string
over plain C strings: they contain the length and thus will be faster in many scenarios. Usestd::vector
instead of plain arrays. This will avoid errors in so many places. Avoid raw pointers like the plague. Using smart pointers might use slightly more memory (depends on the smart pointer type and an optional deleter), but it is so worth the hassle of remembering to delete everything yourself. Basically, use RAII wherever you can. You'd be surprised how often C++ can be better optimized than a list of hard-coded C instructions. Then profile and if there is a place that needs tuning, you can try if a more C-like approach actually helps. BTW C++ has the zero-overhead principle: You don't pay a performance penalty for the features you don't use. Be careful, though, which features you use, like in the example with virtual functions.