@mbruel said:

What do you think, still something to avoid?

You do want to free your resources, while this is usually done in the destructor, that might not always be the case (for example QFile has open() and close() methods, and internal state that it tracks.

For speed optimisation and avoiding signal/slots when possible, well I don't know... I'm new to async programming and still don't really see the point to use a signal/slot mechanism with direct connection instead of directly calling the function on the object. It might not optimize a lot but it should definitely avoid few functions calls and passing by the event queue.

When you connect objects that live in the same thread, you don't have any event queue calls (it's a direct connection, and behaves exactly like you've invoked the function yourself). A reason why you might want to use signals and slots, instead of pure function calls is to decouple components, which is something you'd want for the most part.

I'm wondering if the impressive results of the QT version are due to the C++ and use of native socket or more of the non blocking sockets.

Probably both, although internally (at the OS level) the sockets are blocking, you just don't see it. Also linux sockets, at least to my experience, tend to perform better than their windows counterparts. I don't know why, they just seem to be faster.