Is it safe to create QTcpServer on stack.

[babu198649]

hi
Does Creating a QTcpSocket or QTcpServer on a socket will create a problem(especially in Threading applications)
Thank you.

[jpn]

Why would it create a problem? Except that it goes out of scope unless you block the execution with an event loop or so.

[babu198649]

In the Fortune Client Example QTcpSocket is declared as pointer ,Whereas in the Blocking Fortune Client Example the QTcpSocket is declared without pointer.Does it makes any difference if dont declare QTcpSocket as pointer in the First case.

[jpn]

In the Fortune Client Example QTcpSocket is declared as pointer

It's allocated on the heap, because it's created in the constructor and it must remain alive after the constructor. If it was on the stack, the socket object would get automatically destructed after going out of scope, according to normal C++ rules.

Whereas in the Blocking Fortune Client Example the QTcpSocket is declared without pointer.

Because that example uses waitForXXX() methods to block until certain operations have finished. In that case the object remains alive long enough anyway, so there is no need to allocate it on the heap.

[babu198649]

It's allocated on the heap, because it's created in the constructor and it must remain alive after the constructor.

But it is declared in the private section of the class,So it should be visible to entire class Same as quint16 blockSize variable(please correct me ,i am sure i am missing important concept).

[jpn]

But it is declared in the private section of the class,So it should be visible to entire class Same as quint16 blockSize variable(please correct me ,i am sure i am missing important concept).

If you allocate it on the stack as a member variable and you accidentally happen to pass a parent object, you might get a crash due to double delete; 1) by its parent 2) when going out of scope. Of course you can do it, but you have to be very careful not to break things. Allocating QObjects on the heap with correct parent is less error-prone, I'd say. Furthermore, even if it's not that huge advantage, this also makes a forward declaration sufficient in the header file.