A console application doesn't support some classes.

[jenya7]

@MrShawn
I see. So it should be a class.
And without a class - is there any way to invoke &QUdpSocket::readyRead event?

[mrjj]

@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(); }
    );

[jenya7]

@mrjj
Wow. Thank you. That is good

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

[mrjj]

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

[jenya7]

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

[KroMignon]

@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

[jenya7]

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

[KroMignon]

@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

[jenya7]

@KroMignon
I see. Thank you.

[SimonSchroeder]

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