How to inherit correct canReadLine()

[The Storm]

I want to inherit canReadLine() from QTcpSocket so to make it to return true if there is newline '\n' but not to care if the other simbols can be read or not.
From the documentation:


Note that unbuffered devices, which have no way of determining what can be read, always return false.

I don't want this function to care what is the data I just want to return true if somewhere there is newline. I inherited QTcpSocket and overloaded the function in to the my new class but I don't know what to put in it. Can someone help me this time pleace.

Regards,
The Storm

[wysota]

Hmm... a socket is surely a buffered device and the default implementation of canReadLine() works fine with it.

[The Storm]

Thanks, after some tests it seems that you are right. :)
One more question is readLine() called from the TcpSocket appends a terminating C character at the end of the string - '\0' ?

[wysota]

Thanks, after some tests it seems that you are right.
Yeah, I know that - I have used canReadLine() with QTcpSocket more than once :)


One more question is readLine() called from the TcpSocket appends a terminating C character at the end of the string - '\0' ?
readLine returns a QByteArray, which I think is internally null terminated. But in general the last readable character in the string will be the newline character. You usually use it like so:

while(sock->canReadLine()){
QString dat = sock->readLine();
dat = dat.trimmed(); // removes leading and trailing whitespaces
doSomethingWith(dat);
}

Remember that QString uses 16b unicode so it is in general not null terminated (or to be precise a null character can exist inside the string).

[The Storm]

Thanks alot, this trimmed() function is really usefull, it saves me some operation with the protocol that I'm parsing. :) Just one more question that is not related to the topic but I think that creating new one again will be to much for this days huh. :P
Is it good on client side to put the TcpSocket in other thread, because sometimes when the server side send things very fast I got error from server that the "socket is not ready" or something like that and if I put it in other thread will this problem dissapear and how I will be able to connect the signals from the QTcpSocket to the main GUI thread ? :)

[wysota]

Is it good on client side to put the TcpSocket in other thread, because sometimes when the server side send things very fast I got error from server that the "socket is not ready" or something like that and if I put it in other thread will this problem dissapear and how I will be able to connect the signals from the QTcpSocket to the main GUI thread ? :)

I don't know if the problem will disappear - I sincerely doubt that. Socket not being ready is probably some local issue independent of both the protocol or the speed of data flow, tcp should handle that quite nicely just by itself, without Qt interfering.

As for signals, you can safely use them across threads.

[The Storm]

As for signals, you can safely use them across threads.
I know that the singals/slots are thread safe my question was is there a way to get the signals from the QTcpSocket without to define them in to the Thread class that I will create. :)

[wysota]

is there a way to get the signals from the QTcpSocket without to define them in to the Thread class that I will create. :)

Yes, of course. Just perform the connection from within an object that has pointers to both the sender and receiver.