Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

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 ?


  • Moderators

    @jenya7 did you add QT += network and QT += core?



  • @J-Hilk , @jsulm
    Doubtless correct.

    So that I know for the future: these +=s do not just affect what libraries are linked with, they also affect the include path, and Qt header files are placed in different directories?


  • Lifetime Qt Champion

    @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?


  • Moderators

    @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?


  • Lifetime Qt Champion

    @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_Syntax

    see section "Asynchronous made easier"

    QObject::connect(
            socket, &QTcpSocket::readyRead,
            [socket]() { qDebug() << "GOT DATA " << socket->readAll(); }
        );
    


  • @mrjj
    Wow. Thank you. That is good

    The new syntax can even connect to functions, not just QObjects:
    connect(
        sender, &Sender::valueChanged,
        someFunction
    );
    
    

  • Lifetime Qt Champion

    @jenya7

    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 compiles

    QObject::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. Using virtual 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. Prefer std::string over plain C strings: they contain the length and thus will be faster in many scenarios. Use std::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.


Log in to reply